IETF Logo Mail Archive

Re: [Softwires] MAP Open issues: Interface-id

jouni korhonen <jouni.nospam@gmail.com> Tue, 08 November 2011 09:22 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288B921F8C70 for <softwires@ietfa.amsl.com>; Tue, 8 Nov 2011 01:22:35 -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 t5TKmwlcNhQq for <softwires@ietfa.amsl.com>; Tue, 8 Nov 2011 01:22:34 -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 6244721F8B73 for <softwires@ietf.org>; Tue, 8 Nov 2011 01:22:34 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so252703bkb.31 for <softwires@ietf.org>; Tue, 08 Nov 2011 01:22:32 -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=sC4o9FTy92Lsaew7ZRbGQnvSAsLLKk5nW3mMdEHm9eg=; b=ScQPi98kqMzuI5nVsSDYiwD7j6uLAMR/+hvceFCWAqhO7yNweI/M6nPyJDxsptnYfz x18OH3I6NvVYi3OrPIjIAPV4VRZOWwP0k2PG1yy713+7Rhf1N+7HwI/2Smg5QU/B1UNr XDF+apdQo4+6UeCSf45Ebi4CeiM0CtwdLrtrU=
Received: by 10.205.127.134 with SMTP id ha6mr1476759bkc.23.1320744152799; Tue, 08 Nov 2011 01:22:32 -0800 (PST)
Received: from a83-245-211-74.elisa-laajakaista.fi (a83-245-211-74.elisa-laajakaista.fi. [83.245.211.74]) by mx.google.com with ESMTPS id z7sm851922bka.1.2011.11.08.01.22.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 01:22:31 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <4230DBF5-9EA6-43F9-B6D8-3E34DCF8082D@cisco.com>
Date: Tue, 08 Nov 2011 11:22:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C37EF5B-BBE0-4845-A0ED-5411DF68C561@gmail.com>
References: <703EB6B3-AB8C-4690-91C6-2666C5779874@cisco.com> <9D6EBB21-38BC-4E6C-99E6-C3448FA2D3C8@laposte.net> <CAM+vMESudUt5PT+qxQED_P2s7DB7T+3D_M4OWQ1yUvNN-xqhzA@mail.gmail.com> <C09B8E42-A13F-4B30-AC88-43F98C709EDD@cisco.com> <BC2F2710-0097-4BA6-BE88-A4E3DCD8C537@laposte.net> <4230DBF5-9EA6-43F9-B6D8-3E34DCF8082D@cisco.com>
To: Ole Troan <ot@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] MAP Open issues: Interface-id
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2011 09:22:35 -0000

On Nov 8, 2011, at 11:17 AM, Ole Troan wrote:

[snip]

>>> 
>>> the MAP node cannot any longer listen to a single IPv6 address for MAP traffic, but has to intercept packets for a whole prefix.
>> 
>> - BR's of double translation have always had this property.
>> - Talking with Mark townsley, I got the understanding that this wasn't a real problem, at least with IOS.
> 
> everything can be _implemented_, that's not the point.
> 
>> => Clarifying this point would IMHO be useful. 
> 
> it is clearly requiring bigger changes to tunnel code. which unlike NAT code is attached to 'one' endpoint.
> it makes co-existence of a MAP endpoint and native IPv6 nodes within a single /64 much harder.
> 
> let us turn this around. what's the point in embedding a new set of CNP bits in the IPv6 address, when the L4 checksum can be incrementally updated. that's what everyone has existing code to do already...

I definitely agree with Ole here.

- Jouni

> 
> cheers,
> Ole
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

v2.23.0 | Report a Bug | By Email