Re: [nat66] NPTv6 deals with "packets", not with "datagrams" - to be corrected after draft-14

Fred Baker <fred@cisco.com> Tue, 03 May 2011 21:33 UTC

Return-Path: <fred@cisco.com>
X-Original-To: nat66@ietfa.amsl.com
Delivered-To: nat66@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EE7E06CB; Tue, 3 May 2011 14:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.568
X-Spam-Level:
X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ST6TtqnkLap4; Tue, 3 May 2011 14:33:50 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE7FE0663; Tue, 3 May 2011 14:33:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=724; q=dns/txt; s=iport; t=1304458430; x=1305668030; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=2INTiR/sS9hasZ8sfPQk6b8cRizXmah9Sx7llv3CCcY=; b=a44rw4OmGXnHSpKLJRl9VZIoaL7nFRuncAjuRbNOmwqXlOf4BeoxRzBG 6WcwDQLciJyMR3QQBShmkO/xj1TUa/r8dtd9NNZBxXBQ02s0fkIjI1bah 5mgRKLyEKcZO970LFNu2nw5H0QmFsVe3/6ljahFN8vKgX4nltj07EVHL2 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAGd0wE2rRDoI/2dsb2JhbACmHneIcp8PnhuGAgSGJYhzhBqKOA
X-IronPort-AV: E=Sophos;i="4.64,311,1301875200"; d="scan'208";a="349714984"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 03 May 2011 21:33:50 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p43LXjv7021469; Tue, 3 May 2011 21:33:49 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 03 May 2011 14:33:48 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 03 May 2011 14:33:48 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <BANLkTi=_BtBYugWUCJJdnoRcd0heLhsnDQ@mail.gmail.com>
Date: Tue, 03 May 2011 14:33:33 -0700
Message-Id: <80F2B3A4-84A2-48F9-8D5F-686707D8B2FD@cisco.com>
References: <20110314063002.28048.29694.idtracker@localhost> <19F3A4CD-F39C-4F17-A6E9-7AA8AFBC6B3B@cisco.com> <CF8367A6-F303-43D7-99C6-D40D1DD5D5D9@free.fr> <87C8BBB5-2B11-412E-B788-1538CBE03FB4@cisco.com> <067FF1C8-985D-49B7-AF8D-86A0F337CB9D@free.fr> <B6BD718F-6940-4ECE-833C-670052DB3998@cisco.com> <19D548C2-0644-4E0B-B725-442D0877E044@free.fr> <7F2F3C67-96CC-428E-9453-3EE0480CAFD5@cisco.com> <349CFE54-B2EB-4D79-91BB-0AE7DDA03988@free.fr> <038FC1DC-E0B3-4646-98F1-BFA637BED48D@cisco.com> <BANLkTi=_BtBYugWUCJJdnoRcd0heLhsnDQ@mail.gmail.com>
To: Scott Brim <scott.brim@gmail.com>
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: IESG <iesg@ietf.org>, NAT66 HappyFunBall <nat66@ietf.org>
Subject: Re: [nat66] NPTv6 deals with "packets", not with "datagrams" - to be corrected after draft-14
X-BeenThere: nat66@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "List for discussion of IPv6-to-IPv6 NAT." <nat66.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nat66>, <mailto:nat66-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nat66>
List-Post: <mailto:nat66@ietf.org>
List-Help: <mailto:nat66-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2011 21:33:50 -0000

On May 3, 2011, at 1:54 PM, Scott Brim wrote:

> Dave: "user datagram" as in UDP refers to exposing the datagram interface to the user.  "This User Datagram  Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication": a "datagram mode" is "made available", that is, the user can send datagrams directly instead of offering a stream or a file that is magically chopped up into datagrams for him.  "User datagram" is not a new meaning of datagram.

Yes. I find myself looking at the various definitions of the term, in IEN48, RFC 1594, and so on, and then looking at the header defined in RFC 768, and looking diligently for the destination address.