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

JFC Morfin <jefsey@jefsey.com> Tue, 03 May 2011 16:20 UTC

Return-Path: <jefsey@jefsey.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 9577CE083E; Tue, 3 May 2011 09:20:30 -0700 (PDT)
X-Quarantine-ID: <xrv8eBLQflpy>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E9 hex): Cc: ... Baker <fred@cisco.com>, R\351mi Despr\351s <rem[...]
X-Spam-Flag: NO
X-Spam-Score: -101.834
X-Spam-Level:
X-Spam-Status: No, score=-101.834 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, 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 xrv8eBLQflpy; Tue, 3 May 2011 09:20:25 -0700 (PDT)
Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 95113E06E4; Tue, 3 May 2011 09:20:10 -0700 (PDT)
Received: from 169.128-227-89.dsl.completel.net ([89.227.128.169]:50397 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from <jefsey@jefsey.com>) id 1QHIKW-0007oe-SS; Tue, 03 May 2011 09:20:09 -0700
Message-Id: <7.0.1.0.2.20110503180430.06100878@jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Tue, 03 May 2011 18:21:20 +0200
To: Louis Pouzin <pouzin@email.enst.fr>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <7F2F3C67-96CC-428E-9453-3EE0480CAFD5@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>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage2.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: "comptoir@cafedu.com" <comptoir@cafedu.com>, NAT66 HappyFunBall <nat66@ietf.org>, iucg@ietf.org, IESG <iesg@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 16:20:30 -0000

Louis,
an interesting discussion between Fred Baker and Rémi Després that 
you could may be clarify about your catenet and datagram. Since this 
(NAT66) is at the core of the IPv6 deployment your help might be precious.
----
Louis,
une discussion interessant entre Fred Baker et Rémi Després que tu 
pourrais sans doute aider à claifier au sujets de tes catenet et 
datagrames. Puisque le sujet (NAT66) est au coeur du déploiement 
d'IPv6 ton aide pourrait être précieuse. L'idée de Fred est de 
permettre une conversion de l'adresse réseau IPv6 actuelle (mobiles, 
déménagement, reconfiguration, multihoming, multi-ISP) avec une 
adresse réseau interne.

Tu retrouveras le Draft de Fred sous : 
http://tools.ietf.org/rfcdiff?url1=draft-mrw-nat66-12&url2=draft-mrw-nat66-14

Cela m'interesse bougrement car c'est net, clair et simple et peut 
facilement être utilisé à mon niveau IUI (côté utilisateur/côté 
réseau) et aider le support de IID (IDv6) de façon transparente en 
utilisant des noms de domaine pour porter la partie IDv6 utilisateur, 
sous IPv6 ou IPv4.

jfc

At 17:03 03/05/2011, Fred Baker wrote:
>From: Fred Baker <fred@cisco.com>
>To: Rémi Després <remi.despres@free.fr>
>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
>
>
>On May 3, 2011, at 1:38 AM, Rémi Després wrote:
> >> I also am confused by your use of the term "datagram". A 
> datagram is not a transport layer construct,
> >
> > Isn't User Datagram Protocol a transport layer protocol?
>
>Yes, and unless the datagram is carried in IP, it's not actually a 
>datagram. I refer you to the definition of the term. A datagram is 
>self-addressed and contains all of the information necessary to 
>deliver it from its source to its destination.
>
> >> it's a network layer construct. 
> http://dictionary.reference.com/browse/datagram
> >
> > To know what a datagram is in IETF, RFC's are IMHO better than an 
> online dictionary
>
>If you want to play that game, so be it. The word "datagram" (along 
>with "catenet", which has largely been replaced by the term 
>"internet", in lwer case) was common in the 1970's and 1980's, and 
>the definition was well known to those present. So I don't find a 
>place that says "when I say 'datagram' I mean '...'" in the RFC 
>series - that was in published conference papers circa 1972 when the 
>datagram model was first being proposed as an alternative to virtual 
>circuits. What I do find, however, is this in IEN #48. The Internet 
>Engineering Notes (IENs) were  a parallel document track used in the 
>1970's. IEN #48 is "The Catenet Model for Internetworking", written 
>by Vint Cerf. It says, among its assumptions, that
>
>         it is assumed that the
>         participating network allows switched access so that any source
>         computer can quickly enter datagrams for successive and different
>         destination computers with little or no delay (i.e., on the order
>         of tens of milliseconds or less switching time).
>
>         Under these assumptions, we can readily include networks which
>         offer "datagram" interfaces to subscribing host computers.  That
>         is, the switching is done by the network based on a destination
>         address contained in each datagram passing across the host to
>         network interface.
>
>A datagram is, unlike a packet carried in a virtual circuit, a 
>message that carries its own destination address and can therefore 
>be routed by the network without setting up such a circuit first.
>
> > I hope the IESG won't accept your new interpretation.
>
>Well, if they have a problem with it, they can ask the designers of 
>the architecture for their opinions. "Datagram" is a well known and 
>well understood term.