[Hipsec] Teredo and HIP mobility/NAT
Robert Moskowitz <rgm@htt-consult.com> Fri, 23 May 2014 11:55 UTC
Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2D71A0166 for <hipsec@ietfa.amsl.com>; Fri, 23 May 2014 04:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJtgiFVwSOsX for <hipsec@ietfa.amsl.com>; Fri, 23 May 2014 04:54:59 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 28A0B1A017F for <hipsec@ietf.org>; Fri, 23 May 2014 04:54:59 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 53F53634C2 for <hipsec@ietf.org>; Fri, 23 May 2014 11:54:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMlfA6qIF0UF for <hipsec@ietf.org>; Fri, 23 May 2014 07:54:47 -0400 (EDT)
Received: from lx120e.htt-consult.com (lx120e2.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 11D52634B4 for <hipsec@ietf.org>; Fri, 23 May 2014 07:54:47 -0400 (EDT)
Message-ID: <537F3706.8020805@htt-consult.com>
Date: Fri, 23 May 2014 07:54:46 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: hipsec@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/F1LmN8ElBvteGv0ajaDPhdwOR8I
Subject: [Hipsec] Teredo and HIP mobility/NAT
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 11:55:01 -0000
I have thought a lot about this and generally it works out bad no matter how you slice it. Well, if I was writing the network kernel, I would incorporate Teredo so that all interfaces presented an IPv6 address at all times and if it had a 'native' IPv6 would not use Teredo. Basically tying Teredo right into the interface handling? We have probably all thought long and hard about this. Multiple interfaces, most of them mobile. They are suppose to be changing their priority based on something or other (IEEE 802.21?) IPv6 should be IPv6 publicly routable. But IPv4 will change from public, to good NAT, to bad NAT, and bounce around. Because of this bad mix of reality we go to the lowest common denominator and do everything as if there is a bad NAT in the way. We have no effective method of intelligently switching. HIP everywhere does not fix bad NATs. Networking reality basically xxxxx, well I do try and control my language in public.
- [Hipsec] Teredo and HIP mobility/NAT Robert Moskowitz
- Re: [Hipsec] Teredo and HIP mobility/NAT Miika Komu