From HeinerHummel@aol.com Wed Sep 2 06:56:34 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D3728C5A1 for ; Wed, 2 Sep 2009 06:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA0OjvuzYEQA for ; Wed, 2 Sep 2009 06:56:33 -0700 (PDT) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by core3.amsl.com (Postfix) with ESMTP id B86C13A67E3 for ; Wed, 2 Sep 2009 06:56:32 -0700 (PDT) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id n82DuAIE026411 for ; Wed, 2 Sep 2009 09:56:10 -0400 Received: from HeinerHummel@aol.com by imo-da04.mx.aol.com (mail_out_v42.5.) id 9.d2f.490b37d7 (29672) for ; Wed, 2 Sep 2009 09:56:09 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Wed, 2 Sep 2009 09:56:56 EDT To: rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1251899816" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [rrg] RRG Mobility Architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 13:56:34 -0000 -------------------------------1251899816 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit While mobility aspects pop up in the LISP-discussion, I like to refer to some mobility aspect here on the rrg-list. The issue "mobile node" needs adequate consideration. A future proven solution shouldn't have to worry even if ALL nodes were mobile. Currently mobility is defined as "moving relatively to the non-mobile nodes".However there exists one static non-mobile abstract network which is the grid of longitudes and latitudes. By coming up with a relativity towards this stable and never changing grid any node/router can be whatsoever: fix (for a while) or mobile (all the time). And IP-addresses can be whatsoever too: PA or PI. While giving up the current meaning for forwarding IP addresses they might take on other meanings: I read some article static that Cisco officials consider smartgrid powerline networks to become a second huge topic.Well readdressing might envision AFI's of different technologies !? Heiner -------------------------------1251899816 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
While mobility aspects pop up in the LISP-discussion, I like to = refer=20 to some mobility aspect here on the rrg-list. 
The issue "mobile node" needs adequate consideration. A future proven= =20 solution shouldn't have to worry even if ALL nodes were mobile.
Currently mobility is defined as "moving relatively to the non-mobile= =20 nodes".However there exists one static non-mobile abstract network which= is the=20 grid of longitudes and latitudes.
By coming up with a relativity towards this stable and never changing= grid=20 any node/router can be whatsoever: fix (for  a while) or mobile (all&= nbsp;=20 the time).
 
And IP-addresses can be whatsoever too: PA or PI.
While giving up the current meaning for forwarding IP addresses= they=20 might take on other meanings:
 
I read some article static that Cisco officials consider smartgrid=20 powerline networks to become a second huge topic.Well readdressing mi= ght=20 envision AFI's of different technologies !?
 
Heiner
 
 
 
 
 -------------------------------1251899816-- From irtf@tonistoev.info Wed Sep 2 11:54:59 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF30B3A6D3B for ; Wed, 2 Sep 2009 11:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=1.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiTQwN+g1QfD for ; Wed, 2 Sep 2009 11:54:59 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 18B6B3A69F7 for ; Wed, 2 Sep 2009 11:54:59 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Miuy4-0002OA-QP for rrg@irtf.org; Wed, 02 Sep 2009 21:54:04 +0300 From: Toni Stoev To: IRTF RRG Date: Wed, 2 Sep 2009 21:54:03 +0300 User-Agent: KMail/1.9.9 References: <200909022047.42948.irtf@tonistoev.info> In-Reply-To: <200909022047.42948.irtf@tonistoev.info> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909022154.03947.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] RRG Mobility Architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 18:55:00 -0000 All nodes are potentially mobile. In order to be findable on the general network, mobile nodes need care of their location. For that they have to be recognized by identity, as all nodes should. Toni Stoev On Wednesday 2 September 2009 20:47:42 Toni Stoev wrote: > Mobile node is a dynamically multihomed node. > > Toni > > > On Wednesday 2 September 2009 16:56:56 HeinerHummel@aol.com wrote: > > While mobility aspects pop up in the LISP-discussion, I like to refer to > > some mobility aspect here on the rrg-list. > > The issue "mobile node" needs adequate consideration. A future proven > > solution shouldn't have to worry even if ALL nodes were mobile. > > Currently mobility is defined as "moving relatively to the non-mobile > > nodes".However there exists one static non-mobile abstract network which is the > > grid of longitudes and latitudes. > > By coming up with a relativity towards this stable and never changing grid > > any node/router can be whatsoever: fix (for a while) or mobile (all the > > time). > > > > And IP-addresses can be whatsoever too: PA or PI. > > While giving up the current meaning for forwarding IP addresses they might > > take on other meanings: > > > > I read some article static that Cisco officials consider smartgrid > > powerline networks to become a second huge topic.Well readdressing might envision > > AFI's of different technologies !? > > > > Heiner > > > > > > > > > > > From irtf@tonistoev.info Wed Sep 2 12:14:58 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E41028C17E for ; Wed, 2 Sep 2009 12:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zASnibDDC5Sh for ; Wed, 2 Sep 2009 12:14:57 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 4015628C136 for ; Wed, 2 Sep 2009 12:14:57 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Mitvs-0000dh-NE for rrg@irtf.org; Wed, 02 Sep 2009 20:47:44 +0300 From: Toni Stoev To: IRTF RRG Date: Wed, 2 Sep 2009 20:47:42 +0300 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909022047.42948.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] RRG Mobility Architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 19:14:58 -0000 Mobile node is a dynamically multihomed node. Toni On Wednesday 2 September 2009 16:56:56 HeinerHummel@aol.com wrote: > While mobility aspects pop up in the LISP-discussion, I like to refer to > some mobility aspect here on the rrg-list. > The issue "mobile node" needs adequate consideration. A future proven > solution shouldn't have to worry even if ALL nodes were mobile. > Currently mobility is defined as "moving relatively to the non-mobile > nodes".However there exists one static non-mobile abstract network which is the > grid of longitudes and latitudes. > By coming up with a relativity towards this stable and never changing grid > any node/router can be whatsoever: fix (for a while) or mobile (all the > time). > > And IP-addresses can be whatsoever too: PA or PI. > While giving up the current meaning for forwarding IP addresses they might > take on other meanings: > > I read some article static that Cisco officials consider smartgrid > powerline networks to become a second huge topic.Well readdressing might envision > AFI's of different technologies !? > > Heiner > > > > > From HeinerHummel@aol.com Thu Sep 3 01:12:44 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F563A6AE6 for ; Thu, 3 Sep 2009 01:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIHT6mDN+0El for ; Thu, 3 Sep 2009 01:12:43 -0700 (PDT) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by core3.amsl.com (Postfix) with ESMTP id 8D5A63A6AC9 for ; Thu, 3 Sep 2009 01:12:42 -0700 (PDT) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id n837p0ff020755; Thu, 3 Sep 2009 03:51:00 -0400 Received: from HeinerHummel@aol.com by imo-ma01.mx.aol.com (mail_out_v42.5.) id a.cf3.5d4896d4 (65099); Thu, 3 Sep 2009 03:50:56 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 3 Sep 2009 03:51:32 EDT To: irtf@tonistoev.info, rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1251964292" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [rrg] RRG Mobility Architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 08:12:44 -0000 -------------------------------1251964292 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 02.09.2009 20:56:08 Westeurop=E4ische Sommerzeit schrei= bt =20 irtf@tonistoev.info: All nodes are potentially mobile. In order to be findable on the general network, mobile nodes need care of= =20 their location. For that they have to be recognized by identity, as all= =20 nodes should. whatever identity means with respect to whichever layer; and because the= IP=20 address fails to be the right identity information some location=20 information is needed (instead or at least in addition). =20 LISP is a jackup solution. Its means are typical: mapping and tunnel =20 building (wrapping, encapsulating).=20 It tries to adjust the future to the past. Somehow it reminds me of MADCA= P. Heiner On Wednesday 2 September 2009 20:47:42 Toni Stoev wrote: > Mobile node is a dynamically multihomed node. >=20 > Toni >=20 >=20 > On Wednesday 2 September 2009 16:56:56 HeinerHummel@aol.com wrote: > > While mobility aspects pop up in the LISP-discussion, I like to refer= =20 to=20 > > some mobility aspect here on the rrg-list. =20 > > The issue "mobile node" needs adequate consideration. A future proven= =20 > > solution shouldn't have to worry even if ALL nodes were mobile.=20 > > Currently mobility is defined as "moving relatively to the non-mobile= =20 > > nodes".However there exists one static non-mobile abstract network=20 which is the =20 > > grid of longitudes and latitudes. > > By coming up with a relativity towards this stable and never changing= =20 grid =20 > > any node/router can be whatsoever: fix (for a while) or mobile (all= =20 the =20 > > time). > > =20 > > And IP-addresses can be whatsoever too: PA or PI.=20 > > While giving up the current meaning for forwarding IP addresses they= =20 might=20 > > take on other meanings: > > =20 > > I read some article static that Cisco officials consider smartgrid = =20 > > powerline networks to become a second huge topic.Well readdressing=20 might envision=20 > > AFI's of different technologies !?=20 > > =20 > > Heiner > > =20 > > =20 > > =20 > > =20 > > >=20 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg -------------------------------1251964292 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 02.09.2009 20:56:08 Westeurop=E4ische Sommerzeit= schreibt=20 irtf@tonistoev.info:
All=20 nodes are potentially mobile.
In order to be findable on the general= =20 network, mobile nodes need care of their location. For that they have to= be=20 recognized by identity, as all nodes should.
whatever identity means with respect to whichever layer; and because= the IP=20 address fails to be the right identity information some location informati= on is=20 needed (instead or at least in addition).
 
LISP is a jackup solution. Its means are typical: mapping and tunnel= =20 building (wrapping, encapsulating).
It tries to adjust the future to the past. Somehow it reminds me of= =20 MADCAP.

Heiner

On Wednesday 2 September 2009 20:47:42 Toni= Stoev=20 wrote:
> Mobile node is a dynamically multihomed node.
>
&= gt;=20 Toni
>
>
> On Wednesday 2 September 2009 16:56:56=20 HeinerHummel@aol.com wrote:
> > While mobility aspects pop up in= the=20 LISP-discussion, I like to refer  to
> > some mobility aspe= ct=20 here on the rrg-list. 
> > The issue "mobile node" needs ad= equate=20 consideration. A future proven 
> > solution shouldn't have= to=20 worry even if ALL nodes were mobile.
> > Currently mobility is= defined=20 as "moving relatively to the non-mobile 
> > nodes".However= there=20 exists one static non-mobile abstract network which is the 
>= >=20 grid of longitudes and latitudes.
> > By coming up with a relativ= ity=20 towards this stable and never changing grid 
> > any node/r= outer=20 can be whatsoever: fix (for  a while) or mobile (all   the= =20
> > time).
> > 
> > And IP-addresses can= be=20 whatsoever too: PA or PI.
> > While giving up the current meanin= g for=20 forwarding IP addresses they  might
> > take on other=20 meanings:
> > 
> > I read some article static that= Cisco=20 officials consider smartgrid 
> > powerline networks to bec= ome a=20 second huge topic.Well readdressing might  envision
> > AFI= 's of=20 different technologies !?
> > 
> > Heiner
>= =20 > 
> > 
> > 
> >  >=20 >
>


_______________________________________________rrg=20 mailing=20 list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
=
 
-------------------------------1251964292-- From irtf@tonistoev.info Thu Sep 3 14:19:38 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9EA3A6836 for ; Thu, 3 Sep 2009 14:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4njxRpVfkax for ; Thu, 3 Sep 2009 14:19:37 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 2A5173A6834 for ; Thu, 3 Sep 2009 14:19:34 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MjIyx-00012n-S5 for rrg@irtf.org; Thu, 03 Sep 2009 23:32:35 +0300 From: Toni Stoev To: IRTF RRG Date: Thu, 3 Sep 2009 23:27:06 +0300 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200909032327.06575.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] RRG Mobility Architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:19:38 -0000 On Thursday 3 September 2009 10:51:32 HeinerHummel@aol.com wrote: > In einer eMail vom 02.09.2009 20:56:08 Westeurop=C3=A4ische Sommerzeit sc= hreibt =20 > irtf@tonistoev.info: >=20 > > All nodes are potentially mobile. > > In order to be findable on the general network, mobile nodes need care= of=20 > > their location. For that they have to be recognized by identity, as al= l=20 > > nodes should. >=20 > whatever identity means with respect to whichever layer; and because the = IP=20 > address fails to be the right identity information some location=20 > information is needed (instead or at least in addition). Heiner, My vision is that identity of nodes is to be based on relations with other = nodes. Especially, mutual knowledge of location within the general network. Maintaining this knowledge continuously and all over the network shall make= node mobility natural and inconspicuous. I seek understanding and opinions on this vision, and I disfavor non-networ= k based identity. Toni > LISP is a jackup solution. Its means are typical: mapping and tunnel =20 > building (wrapping, encapsulating).=20 > It tries to adjust the future to the past. Somehow it reminds me of MADC= AP. >=20 > Heiner >=20 > On Wednesday 2 September 2009 20:47:42 Toni Stoev wrote: > > Mobile node is a dynamically multihomed node. > >=20 > > Toni > >=20 > >=20 > > On Wednesday 2 September 2009 16:56:56 HeinerHummel@aol.com wrote: > > > While mobility aspects pop up in the LISP-discussion, I like to refe= r =20 > to=20 > > > some mobility aspect here on the rrg-list. =20 > > > The issue "mobile node" needs adequate consideration. A future prove= n =20 > > > solution shouldn't have to worry even if ALL nodes were mobile.=20 > > > Currently mobility is defined as "moving relatively to the non-mobil= e =20 > > > nodes".However there exists one static non-mobile abstract network=20 > which is the =20 > > > grid of longitudes and latitudes. > > > By coming up with a relativity towards this stable and never changin= g=20 > grid =20 > > > any node/router can be whatsoever: fix (for a while) or mobile (all= =20 > the =20 > > > time). > > > =20 > > > And IP-addresses can be whatsoever too: PA or PI.=20 > > > While giving up the current meaning for forwarding IP addresses they= =20 > might=20 > > > take on other meanings: > > > =20 > > > I read some article static that Cisco officials consider smartgrid = =20 > > > powerline networks to become a second huge topic.Well readdressing=20 > might envision=20 > > > AFI's of different technologies !?=20 > > > =20 > > > Heiner > > > =20 > > > =20 > > > =20 > > > =20 > > > > >=20 >=20 >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg >=20 >=20 >=20 >=20 From HeinerHummel@aol.com Fri Sep 4 02:32:00 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2B43A68C3 for ; Fri, 4 Sep 2009 02:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGJqZA6Fd28o for ; Fri, 4 Sep 2009 02:31:59 -0700 (PDT) Received: from imr-da03.mx.aol.com (imr-da03.mx.aol.com [205.188.105.145]) by core3.amsl.com (Postfix) with ESMTP id 1D5FC3A69BE for ; Fri, 4 Sep 2009 02:31:58 -0700 (PDT) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-da03.mx.aol.com (8.14.1/8.14.1) with ESMTP id n847vteT016289; Fri, 4 Sep 2009 03:57:55 -0400 Received: from HeinerHummel@aol.com by imo-da04.mx.aol.com (mail_out_v42.5.) id a.d50.56b2739b (65097); Fri, 4 Sep 2009 03:57:50 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Fri, 4 Sep 2009 03:57:50 EDT To: irtf@tonistoev.info, rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1252051070" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [rrg] RRG Mobility Architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 09:32:00 -0000 -------------------------------1252051070 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 03.09.2009 23:20:15 Westeurop=E4ische Sommerzeit schrei= bt =20 irtf@tonistoev.info: Heiner, My vision is that identity of nodes is to be based on relations with othe= r=20 nodes. Whereas my vision is that identity of nodes is to be based on relations to= =20 a neutral third and ever fix grid of "virtual/logical/abstract nodes".=20 Otherwise you can map&encap to death. =20 My impression: people don't want to abolish problems, they rather want to= =20 keep them as a permanent task to be mastered: scalability, looping... They can imagine Scoped Anycast, but not Scoped Anywhere of Unicast =20 users.Here I cannot blame MIP4. They did an excellent job adopting a new= =20 requirement to a concept where roaming was not on the radar screen. LISP= -ALT is a=20 centralized care-of-address concept. What if both users roam as well as= =20 nodes? Potentially all users and all nodes? And even if you ignored the = =20 resulting new scalability and stretch problems you cannot even provide Sco= ped =20 Anywhere service. However if a mobile node roamed within a particular geopatch no change of= =20 information is to be sent to the rest of the world, and also: you may=20 provide the service to search for the destination in its "neighborhood"= =20 eventually without a home agent. By doing less you get much more... =20 Especially, mutual knowledge of location within the general network. Maintaining this knowledge continuously and all over the network shall=20 make node mobility natural and inconspicuous. I seek understanding and opinions on this vision,=20 =20 and I disfavor non-network based identity. without any deeper reasoning ? =20 Heiner =20 =20 -------------------------------1252051070 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 03.09.2009 23:20:15 Westeurop=E4ische Sommerzeit= schreibt=20 irtf@tonistoev.info:
Heiner,

My vision is that identity of nodes is to be= based=20 on relations with other nodes.
Whereas my vision is that identity of nodes is to be based on relatio= ns to=20 a neutral third and ever fix grid of "virtual/logical/abstract nodes". Oth= erwise=20 you can map&encap to death. 
My impression: people don't want to abolish problems, they rather wan= t to=20 keep them as a permanent task to be mastered: scalability, looping...=
They can imagine Scoped Anycast, but not Scoped Anywhere of Unicast= =20 users.Here I cannot blame MIP4. They did an excellent job adopting a new= =20 requirement  to a concept where roaming was not on the radar screen.= =20 LISP-ALT is a centralized care-of-address concept. What if both users roam= as=20 well as nodes? Potentially all users and all nodes? And even if you ignore= d the=20 resulting new scalability and stretch problems you cannot even provide Sco= ped=20 Anywhere service.
However if a mobile node roamed within a particular geopatch no chang= e of=20 information is to be sent to the rest of the world, and also: you may prov= ide=20 the service to search for the destination in its "neighborhood" event= ually=20 without a home agent. By doing less you get much more...
 
Especially, mutual knowledge of location within the general= =20 network.
Maintaining this knowledge continuously and all over the net= work=20 shall make node mobility natural and inconspicuous.
I seek understand= ing=20 and opinions on this vision,
 
and I=20 disfavor non-network based identity.

without any deeper reasoning ?
 
Heiner
 
 
-------------------------------1252051070-- From irtf@tonistoev.info Sun Sep 6 20:03:12 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACEC3A684F for ; Sun, 6 Sep 2009 20:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMrbQe+lk8Jh for ; Sun, 6 Sep 2009 20:03:11 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 338D63A67B4 for ; Sun, 6 Sep 2009 20:03:10 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop-wireless) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MkUVw-0002Y9-Hx for rrg@irtf.org; Mon, 07 Sep 2009 06:03:32 +0300 From: Toni Stoev To: IRTF RRG Date: Mon, 7 Sep 2009 06:03:31 +0300 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200909070603.31776.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] RRG Mobility Architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 03:03:12 -0000 On Friday 4 September 2009 10:57:50 HeinerHummel@aol.com wrote: > In einer eMail vom 03.09.2009 23:20:15 Westeurop=C3=A4ische Sommerzeit sc= hreibt =20 > irtf@tonistoev.info: >=20 > > Heiner, > >=20 > > My vision is that identity of nodes is to be based on relations with o= ther=20 > > nodes. >=20 >=20 > Whereas my vision is that identity of nodes is to be based on relations t= o =20 > a neutral third and ever fix grid of "virtual/logical/abstract nodes".=20 > Otherwise you can map&encap to death. =20 > My impression: people don't want to abolish problems, they rather want to= =20 > keep them as a permanent task to be mastered: scalability, looping... "We fix it this way. Who needs a general solution?" > They can imagine Scoped Anycast, but not Scoped Anywhere of Unicast =20 > users.Here I cannot blame MIP4. They did an excellent job adopting a new = =20 > requirement to a concept where roaming was not on the radar screen. LIS= P-ALT is a=20 > centralized care-of-address concept. What if both users roam as well as= =20 > nodes? Potentially all users and all nodes? And even if you ignored the = =20 > resulting new scalability and stretch problems you cannot even provide Sc= oped =20 > Anywhere service. > However if a mobile node roamed within a particular geopatch no change of= =20 > information is to be sent to the rest of the world, and also: you may=20 > provide the service to search for the destination in its "neighborhood"= =20 > eventually without a home agent. By doing less you get much more... > =20 >=20 >=20 > > Especially, mutual knowledge of location within the general network. > > Maintaining this knowledge continuously and all over the network shall= =20 > > make node mobility natural and inconspicuous. > > I seek understanding and opinions on this vision,=20 > =20 >=20 > > and I disfavor non-network based identity. >=20 >=20 >=20 > without any deeper reasoning ? If node identity depends on a network-external place-based grid and the pla= ce of networking changes, then identity becomes legacy. The general network is to be ubiquitous and shall have the solutions of its= problems within itself. > Heiner > =20 > =20 >=20 Regards, Toni From olivier.bonaventure@uclouvain.be Wed Sep 16 03:17:09 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298A83A69D8 for ; Wed, 16 Sep 2009 03:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGpBYMuMJ86N for ; Wed, 16 Sep 2009 03:17:08 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id C4CA63A6AC2 for ; Wed, 16 Sep 2009 03:17:07 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id D80FAEBA75 for ; Wed, 16 Sep 2009 12:16:10 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp2.sgsi.ucl.ac.be D80FAEBA75 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1253096171; bh=ORwh0BPWIy+N7jGrAMKHLWfvMYFTgSJbfvC7d0gq14M=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=ecsXh+pzKgL6BiG6dKNLSe3Vz+Q1AT8oda/SdtuU6K7J0BDIqFR4+rjTef8LJPx21 lFfB4DaIrbNMkPy1WojJeXNplLgsL5AXyy3ujJGXQavKdbtWPjHkeQIY1ZdQ0DwCZh 4Wr9dqd6zTt0WpHTlQraM/MLSvyAx2JgHgI16Dkw= Message-ID: <4AB0BAEA.4050605@uclouvain.be> Date: Wed, 16 Sep 2009 12:16:10 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: RRG X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-2.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: D80FAEBA75.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [rrg] Tutorials on Future Internet X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 10:17:09 -0000 Hello, There have been lots of discussion in RRG concerning issues related to the future Internet architecture. During the last week of August, we organised in the framework of the Trilogy project a summer school dedicated to this topic. The scientific program contained both poster sessions and long tutorials by renowned experts : Paul Francis (MPI-SWS) - Dirty-slate approaches to scaling global Internet routing Lars Eggert (Nokia) - Standardization Activities in the IETF/IRTF Janardhan Iyengar (Franklin & Marshall College) - Rethinking Transport Layering Bruno Quoitin (UCL) & Cristel Pelsser (IIJ) - Realistic interdomain routing simulations with C-BGP and Igen Bob Briscoe (BT-Network Research Center) - Practical Microeconomics and Internet Resource Sharing Protocols Olivier Bonaventure (UCL) - Scaling the Internet with the Locator/Identifier Separation Protocol (LISP) Mathieu Lacage (INRIA) - Network experimentation and simulation with ns-3 Timothy Griffin (Cambridge University) - From Semirings to Metarouting Dimitri Papadimitriou (Alcatel-Lucent) - Compact Routing: Challenges, Perspectives, and Beyond All these presentations were recorded and we are happy to announce that they are now available from : http://inl.info.ucl.ac.be/TFISS09 Best regards, Olivier Bonaventure -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From Fred.L.Templin@boeing.com Fri Sep 18 15:00:20 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4D128C182 for ; Fri, 18 Sep 2009 15:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N17M+Zi1FQZl for ; Fri, 18 Sep 2009 15:00:19 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 7A84328C118 for ; Fri, 18 Sep 2009 15:00:18 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8IM1AJF020359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 18 Sep 2009 15:01:11 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n8IM1Ao9009917 for ; Fri, 18 Sep 2009 15:01:10 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n8IM1A77009914 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 18 Sep 2009 15:01:10 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Fri, 18 Sep 2009 15:01:09 -0700 From: "Templin, Fred L" To: RRG Date: Fri, 18 Sep 2009 15:01:08 -0700 Thread-Topic: 6to4++ Thread-Index: Aco2tvl5OPXoDmyETlS/p+PE6AFuMQB8j33g Message-ID: <12F4112206976147A34FEC0277597CCF27A406223A@XCH-NW-15V.nw.nos.boeing.com> References: <4AB0BAEA.4050605@uclouvain.be> In-Reply-To: <4AB0BAEA.4050605@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-5.600.1016-16888.004 x-tm-as-result: No--54.781500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rrg] 6to4++ X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 22:00:20 -0000 Hi, I think it should be obvious from the discussions on this and other lists that the mapping considerations for any map/encaps scheme are the hard part. I think this has been known for a very long time, and I'm sure there are folks watching these discussions who are seeing issues rehashed that they have known about for years. As such, it might be worth considering whether a stateless mapping capability is possible. As it turns out, for IPv6-in-IPv4 encapsulation a stateless mapping is possible when the IPv6 EID address embeds the IPv4 RLOC address. This is the case for schemes such as 6to4, 6rd and isatap. 6to4 in particular was designed to support router-to-router tunneling between DFZ routers, where the ITR can determine the ETR's RLOC through a simple stateless extraction of the RLOC from the EID. This eliminates the needs for a mapping database, delaying or dropping initial packets, alternate topologies, and other cumbersome aspects associated with stateful mapping. So, it might be worth asking whether a stateless mapping scheme such as 6to4's could be used. AFAICT, there are only a few aspects of 6to4 that would limit its applicability as a general solution for EID/RLOC separation in the DFZ. First, 6to4 uses a well-known prefix (WKP) that is rather long if the intention were to use it as the primary routing and addressing mechanism for IPv6 in the Internet DFZ. In particular, 2002::/16 occupies only 1/2^16th of the total IPv6 address space, which means that the rest of the space would expect to use some other form of IPv6 routing and addressing. This may have been an artifact of the original 6to4 design goal of providing only a transition mechanism. But, now that we are seeing proposals to have map/encaps solutions as a core aspect of routing and addressing in the Internet it may be worth revisiting those earlier assumptions. Secondly, each 6to4 IPv6 EID prefix is tied to a single IPv4 RLOC address. This means that if the IPv4 RLOC is down, then the entire IPv6 EID prefix is unreachable. It may be that a multi-addressing scheme would be able to switch gracefully between multiple IPv6 EID prefixes when one goes down, but there are obvious interactions for mobility, session continuity, etc. that would tend to favor a stable and highly-available IPv6 prefix. Thirdly, the ip-proto-41 encapsulation used by 6to4 may have suboptimal interactions with core Internet gear that expects to see only certain IP protocols. Additionally, there is no nonce field nor a bit field for negotiations between the ITR and ETR (e.g., an acknowledgement request bit). It should be easy to see that these shortcomings could be addressed through minor augmentations to the original 6to4 design (for now we can call it '6to4++') to allow for both stateless mapping and more robust communications. First, a much shorter IPv6 well-known prefix 'WKP::/N' could be procured for this stateless mechanism when a small value for N is chosen. When concatenated with the 32-bit IPv4 RLOC as 'WKP:V4ADDR::/(N+32)' this would still give a very short prefix to each holder of a public IPv4 address. Secondly, prefix availability could be greatly enhanced if multiple site border routers configured 'V4ADDR' as an IPv4=20 anycast address such that there would be multiple ETRs available for each IPv6 prefix. In that case, IPv4 routing in the DFZ would direct packets to the nearest available ETR. Finally, the WKP would serve as an indication that a new encapsulation format IPv6-in-(foo)-in-IPv4 is to be used. The (foo) layer could look very much like LISP, SEAL, etc. and it could contain nonces, bitfields, etc. that would make communications between the ITR and ETR more robust. The (foo) layer would also give a handle for the ETR to provide path MTU feedback to the ITR with a useable nonce. In general, I believe that the larger the mapping domain the more cumbersome stateful mapping becomes and the more beneficial stateless mapping becomes. As such, it might be worth considering whether a stateless mapping system via '6to4++' could be used in the Internet DFZ core. Any thoughts? Fred fred.l.templin@boeing.com From jnc@mercury.lcs.mit.edu Fri Sep 18 15:13:08 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8F13A6928 for ; Fri, 18 Sep 2009 15:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLV0g97uwzeK for ; Fri, 18 Sep 2009 15:13:07 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 969853A67DD for ; Fri, 18 Sep 2009 15:13:07 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D46A96BE589; Fri, 18 Sep 2009 18:13:18 -0400 (EDT) To: Fred.L.Templin@boeing.com, rrg@irtf.org Message-Id: <20090918221318.D46A96BE589@mercury.lcs.mit.edu> Date: Fri, 18 Sep 2009 18:13:18 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] 6to4++ X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 22:13:08 -0000 > From: "Templin, Fred L" > a stateless mapping is possible when the IPv6 EID address embeds the > IPv4 RLOC address. What happens when the EID needs to change its RLOC (for provider independence), or use multiple RLOCs (for multihoming)? The whole point of 'separation of location and identity' is that it requires a binding. TANSTAAFL. Noel From Fred.L.Templin@boeing.com Fri Sep 18 15:29:00 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03D03A6940 for ; Fri, 18 Sep 2009 15:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUZ3iOukNsV9 for ; Fri, 18 Sep 2009 15:29:00 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 0A6EE3A68C8 for ; Fri, 18 Sep 2009 15:29:00 -0700 (PDT) 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.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8IMTsRk029105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Sep 2009 15:29:55 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n8IMTs24004950; Fri, 18 Sep 2009 15:29:54 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n8IMTsaJ004942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 Sep 2009 15:29:54 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Fri, 18 Sep 2009 15:29:53 -0700 From: "Templin, Fred L" To: Noel Chiappa , "rrg@irtf.org" Date: Fri, 18 Sep 2009 15:29:52 -0700 Thread-Topic: [rrg] 6to4++ Thread-Index: Aco4rVcN6qdLBXjDTdCAkdhOsW8CewAACxlw Message-ID: <12F4112206976147A34FEC0277597CCF27A406224A@XCH-NW-15V.nw.nos.boeing.com> References: <20090918221318.D46A96BE589@mercury.lcs.mit.edu> In-Reply-To: <20090918221318.D46A96BE589@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-5.600.1016-16888.004 x-tm-as-result: No--54.261800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rrg] 6to4++ X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 22:29:00 -0000 Noel, > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Friday, September 18, 2009 3:13 PM > To: Templin, Fred L; rrg@irtf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [rrg] 6to4++ >=20 > > From: "Templin, Fred L" >=20 > > a stateless mapping is possible when the IPv6 EID address embeds th= e > > IPv4 RLOC address. >=20 > What happens when the EID needs to change its RLOC (for provider > independence), Changing the RLOC obviously changes the EID prefix. Those who are lucky enough to have provider-independent RLOCs will not have a problem with this. Those that don't would incur a site-wide renumbering event if they changed providers. But, the goal here is to support automatic mapping between core DFZ routers with public IPv4 addresses that would presumably be stable; we would not want this scheme to penetrate deeply beyond the core DFZ routers, and would instead use some stateful map/encaps scheme within end sites. > or use multiple RLOCs (for multihoming)? The proposal is that multiple site border routers would configure the same IPv4 RLOC in anycast fashion to give multihoming. Another name that someone suggested for this scheme was "multihomed 6to4" =20 > The whole point of 'separation of location and identity' is that it > requires a binding. TANSTAAFL. The major point to be made is that there are different considerations within different domains of application. Instead of saying "TANSTAAFL", I would rather say "there is no one size fits all". So, stateless mapping using 6to4++ within the core where addresses are more stable, and stateful mapping nearer the edges where addresses are more volatile is what is being proposed here. Fred fred.l.templin@boeing.com >=20 > Noel From jmh@joelhalpern.com Fri Sep 18 15:41:05 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3A83A67F9 for ; Fri, 18 Sep 2009 15:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ5l+DaoKcLN for ; Fri, 18 Sep 2009 15:41:04 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 312DC3A6805 for ; Fri, 18 Sep 2009 15:41:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 95192322C1F5; Fri, 18 Sep 2009 15:41:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-45.clppva.btas.verizon.net [71.161.51.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 0402C3231776; Fri, 18 Sep 2009 15:41:58 -0700 (PDT) Message-ID: <4AB40CB4.5000501@joelhalpern.com> Date: Fri, 18 Sep 2009 18:41:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" References: <20090918221318.D46A96BE589@mercury.lcs.mit.edu> <12F4112206976147A34FEC0277597CCF27A406224A@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A406224A@XCH-NW-15V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rrg@irtf.org" Subject: Re: [rrg] 6to4++ X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 22:41:05 -0000 Sorry Fred. As far as I can tell, attempting to use stateless mapping as you describe it means that very few of the state goals of the RRG work would be met. Yours, Joel Templin, Fred L wrote: > Noel, > >> -----Original Message----- >> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] >> Sent: Friday, September 18, 2009 3:13 PM >> To: Templin, Fred L; rrg@irtf.org >> Cc: jnc@mercury.lcs.mit.edu >> Subject: Re: [rrg] 6to4++ >> >> > From: "Templin, Fred L" >> >> > a stateless mapping is possible when the IPv6 EID address embeds the >> > IPv4 RLOC address. >> >> What happens when the EID needs to change its RLOC (for provider >> independence), > > Changing the RLOC obviously changes the EID prefix. Those > who are lucky enough to have provider-independent RLOCs > will not have a problem with this. Those that don't would > incur a site-wide renumbering event if they changed > providers. But, the goal here is to support automatic mapping > between core DFZ routers with public IPv4 addresses that > would presumably be stable; we would not want this scheme > to penetrate deeply beyond the core DFZ routers, and would > instead use some stateful map/encaps scheme within end sites. > >> or use multiple RLOCs (for multihoming)? > > The proposal is that multiple site border routers would > configure the same IPv4 RLOC in anycast fashion to give > multihoming. Another name that someone suggested for > this scheme was "multihomed 6to4" > >> The whole point of 'separation of location and identity' is that it >> requires a binding. TANSTAAFL. > > The major point to be made is that there are different > considerations within different domains of application. > Instead of saying "TANSTAAFL", I would rather say "there > is no one size fits all". > > So, stateless mapping using 6to4++ within the core where > addresses are more stable, and stateful mapping nearer the > edges where addresses are more volatile is what is being > proposed here. > > Fred > fred.l.templin@boeing.com > >> Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From xuxh@huawei.com Fri Sep 18 18:00:03 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177DC3A68A8 for ; Fri, 18 Sep 2009 18:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.16 X-Spam-Level: * X-Spam-Status: No, score=1.16 tagged_above=-999 required=5 tests=[AWL=1.655, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opyo3QQPpQlk for ; Fri, 18 Sep 2009 18:00:02 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 29D873A657C for ; Fri, 18 Sep 2009 18:00:02 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ700AVE1H4PC@szxga02-in.huawei.com> for rrg@irtf.org; Sat, 19 Sep 2009 09:00:40 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ7001LH1H4TC@szxga02-in.huawei.com> for rrg@irtf.org; Sat, 19 Sep 2009 09:00:40 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ700E4Z1H4ZH@szxml04-in.huawei.com> for rrg@irtf.org; Sat, 19 Sep 2009 09:00:40 +0800 (CST) Date: Sat, 19 Sep 2009 09:00:39 +0800 From: Xu Xiaohu In-reply-to: <12F4112206976147A34FEC0277597CCF27A406224A@XCH-NW-15V.nw.nos.boeing.com> To: "'Templin, Fred L'" , 'Noel Chiappa' , rrg@irtf.org Message-id: <001901ca38c4$9b35a4d0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco4rVcN6qdLBXjDTdCAkdhOsW8CewAACxlwAAVncGA= Subject: Re: [rrg] 6to4++ X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 01:00:03 -0000 Hi Fred, > > What happens when the EID needs to change its RLOC (for provider > > independence), > > Changing the RLOC obviously changes the EID prefix. Those > who are lucky enough to have provider-independent RLOCs > will not have a problem with this. Those that don't would > incur a site-wide renumbering event if they changed > providers. But, the goal here is to support automatic mapping > between core DFZ routers with public IPv4 addresses that > would presumably be stable; we would not want this scheme > to penetrate deeply beyond the core DFZ routers, and would > instead use some stateful map/encaps scheme within end sites. One of the major goals for id/locator split is to make the identifier provider-independent. Embedding the RLOC in the EID will damage this goal. > > or use multiple RLOCs (for multihoming)? > > The proposal is that multiple site border routers would > configure the same IPv4 RLOC in anycast fashion to give > multihoming. Another name that someone suggested for > this scheme was "multihomed 6to4" For a multi-homed site, its multiple border routers should use the same IPv4 RLOC in anycast fashion. It means each multi-homed site should be allocated a unique RLOC. I wonder whether such kind of RLOC is still topologically aggregatable in provider networks. Xiaohu > > The whole point of 'separation of location and identity' is that it > > requires a binding. TANSTAAFL. > > The major point to be made is that there are different > considerations within different domains of application. > Instead of saying "TANSTAAFL", I would rather say "there > is no one size fits all". > > So, stateless mapping using 6to4++ within the core where > addresses are more stable, and stateful mapping nearer the > edges where addresses are more volatile is what is being > proposed here. > > Fred > fred.l.templin@boeing.com > > > > > Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From vijay@gatech.edu Sun Sep 20 02:52:35 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D94F28B797 for ; Sun, 20 Sep 2009 02:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zulotj2auG6L for ; Sun, 20 Sep 2009 02:52:35 -0700 (PDT) Received: from deliverator6.gatech.edu (deliverator6.gatech.edu [130.207.160.71]) by core3.amsl.com (Postfix) with ESMTP id 775D23A67D1 for ; Sun, 20 Sep 2009 02:52:35 -0700 (PDT) Received: from deliverator6.gatech.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 99CCF20C0AB for ; Sun, 20 Sep 2009 05:53:33 -0400 (EDT) Received: from mail6.gatech.edu (mail6.gatech.edu [130.207.185.166]) by deliverator6.gatech.edu (Postfix) with ESMTP id 4DE3520C068 for ; Sun, 20 Sep 2009 05:53:33 -0400 (EDT) Received: from mail6.gatech.edu (localhost [127.0.0.1]) by mail6.gatech.edu (Postfix) with ESMTP id 42BB0225A11 for ; Sun, 20 Sep 2009 05:53:33 -0400 (EDT) Date: Sun, 20 Sep 2009 05:53:33 -0400 (EDT) From: vijay@gatech.edu Sender: vijay@gatech.edu To: rrg@irtf.org Message-ID: <16424644.86181253440413252.JavaMail.root@mail6.gatech.edu> In-Reply-To: <775066204.85121253439536413.JavaMail.root@mail6.gatech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [130.207.185.168] X-Mailer: Zimbra 5.0.16_GA_2921.RHEL5_64 (ZimbraWebClient - FF3.0 (Mac)/5.0.16_GA_2921.RHEL5_64) Subject: [rrg] Subject: NPSec'09: Call for Participation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 09:52:35 -0000 [Apologies if you receive multiple copies of this Call for Participation] ***** Advance registration (lower rates!) ends on September 21. Hotel reservation cutoff date is September 28 ******** We invite you to join us in Princeton, NJ on October 13 for the fifth Workshop on Secure Network Protocols (NPSec'09), co-located with the The 17th IEEE International Conference on Network Protocols (ICNP'09). We have an exciting program with: - seven accepted technical papers - a keynote speech by Prof. S Felix Wu from UC Davis on using social networking to improve routing and security - an invited paper by Prof. Minaxi Gupta from Indiana University - a panel on ethics in network security research More details about the program and the workshop can be found at: http://www.gtisc.gatech.edu/npsec09/ . We hope you can join us in Princeton! Jelena Mirkovic and Xiaowei Yang NPSec'09 co-chairs