Re: [RAM] Different approaches for different protocols

Dino Farinacci <dino@cisco.com> Wed, 19 December 2007 20:46 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55nl-0000rU-F1; Wed, 19 Dec 2007 15:46:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55nk-0000pG-6N for ram@iab.org; Wed, 19 Dec 2007 15:46:00 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J55nj-00071n-P2 for ram@iab.org; Wed, 19 Dec 2007 15:46:00 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Dec 2007 12:45:59 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBJKjxpT012642; Wed, 19 Dec 2007 12:45:59 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBJKjrLG001934; Wed, 19 Dec 2007 20:45:58 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 12:45:53 -0800
Received: from normz.cisco.com ([10.21.80.90]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 12:45:53 -0800
Message-Id: <5DD2D898-A66D-4471-96B3-663E71350302@cisco.com>
From: Dino Farinacci <dino@cisco.com>
To: Scott Brim <swb@employees.org>
In-Reply-To: <20071219174837.GA1342@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [RAM] Different approaches for different protocols
Date: Wed, 19 Dec 2007 12:45:57 -0800
References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> <20071219174837.GA1342@cisco.com>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 19 Dec 2007 20:45:53.0603 (UTC) FILETIME=[25B69930:01C84280]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2190; t=1198097159; x=1198961159; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[RAM]=20Different=20approaches=20for=20 different=20protocols |Sender:=20; bh=wkWQ5FyTtsb8UkXbPugX5WnSUO3sZv4WkB7//0Bg7Qc=; b=iDxbKDGKfOehHs027cxSdL0TYVDAxMHWmVpCYwLnrvau7wgjO0diD+VWZk aWkjrnCls1RkDoGUDfpmRitZA1OzTCljEDEnJfNOoNooOYOYILUpOmTt4FLM tjmDoucyAO;
Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

> To start with we need to evaluate whether an 8+8-style approach is
> better than an map&encap approach *at all*, regardless of address
> family.  If it is -- which is not clear by any means -- then that will
> be the time to consider multiple routing modes.

Scott, the comments I have heard in favor of using map&encap is that  
you maintain the original addresses which the host put in the header.  
You then can build ACLs in various middle-boxes that are based on  
those (inner) addresses that don't change. So for IPv4, I see value  
there.

But for IPv6, those middle boxes can setup ACLs based on the lower- 
order 8-bytes, which, as well as above, will not change. So doing  
address swaps on the high-order 8-bytes doesn't lose information like  
it does in IPv4.

I think a GSE++ approach could work very well. The only worry I have,  
with respect to how it is spec'ed out now is that an entire 128-bits  
is in the DNS. You don't really want to have locators in the DNS. You  
really want to decouple it.

So I would propose this:

1) Put A records in DNS for IPv6 hosts as ::<eid>, where <eid> is 8- 
bytes.

2) Have socket connections use the following addresses for tcb lookups:

	source = ::<source-eid>  dest = ::<dest-eid>

3) CE routers that participate in the mapping database, will do this:

         Make ::<source-eid> into <source-locator>::<source-eid>
	Make ::<dest-eid> into <dest-locator>::<source-eid>

     where:
	<source-locator> is the CE's IPv6 address out of the address block
                          from the provider it is attached to
         <dest-locator>   is the locator returned from a mapping  
database
                          lookup for <dest-id>

4) When the packet enters the destination site, the ETR will translate  
because
    the locator is it's own address, so it changes the source and  
destination
    locator bits to 0.

5) No host changes because the checksums are always based on non-zero  
bits in
    the EID field and 0 bits in the locator field.

We can do this with LISP-ALT as the mapping database mechanism.

Should we prototype this?  Comments?

Dino


	

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram