[Softwires] France Telecom's IPR Statement about 4rd

Rémi Després <despres.remi@laposte.net> Tue, 09 April 2013 15:58 UTC

Return-Path: <despres.remi@laposte.net>
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 5927D21F9428; Tue, 9 Apr 2013 08:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level:
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 VIMUXPJ0QywA; Tue, 9 Apr 2013 08:58:46 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED7521F9057; Tue, 9 Apr 2013 08:58:46 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id CB8FC7000E59; Tue, 9 Apr 2013 17:58:44 +0200 (CEST)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id B34027000E52; Tue, 9 Apr 2013 17:58:44 +0200 (CEST)
X-SFR-UUID: 20130409155844734.B34027000E52@msfrf2111.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <20130405175307.17053.57704.idtracker@ietfa.amsl.com>
Date: Tue, 9 Apr 2013 17:58:44 +0200
Message-Id: <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net>
References: <20130405175307.17053.57704.idtracker@ietfa.amsl.com>
To: Softwires WG <softwires@ietf.org>, Mohamed Boucadair <mohamed.boucadair@orange.com>
X-Mailer: Apple Mail (2.1503)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: IETF Secretariat <ietf-ipr@ietf.org>, ipr-announce@ietf.org
Subject: [Softwires] France Telecom's IPR Statement about 4rd
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, 09 Apr 2013 15:58:47 -0000

Dear Med, dear all,

I carefully checked France Telecom's IPR statement we just received about 4rd.
For reasons detailed below, I found that none of the three listed patents applies to 4rd.

Could you please, Med, check the technical analysis and, if we reach common understanding, see to it that the IPR statement be either deleted or appropriately updated. 

Thanks,
RD


__________________
TECHNICAL ANALYSIS

1. 4rd isn't concerned with patent EP 2294798 because uses of for port numbers for address sharing are radically different.
  
 - In EP 2294798, deriving a destination "identifier" from an original address + port must include these two steps: (1) find which PORT RANGE is matched by the destination port among those that are recorded as relevant to this destination address; (2) take as destination identifier that which is recorded as associated with this address/port-range couple.
  
 - In 4rd, deriving a destination IPv6 address from an IPv4 A+P includes these two steps: (1) find which IPV4 PREFIX is matched by the IPv4 address, among recorded Rule IPv4 prefixes; (2) take as prefix of the IPv6 destination the concatenation of three parts: the Rule IPv6 prefix of the mapping rule that has the found IPv4 prefix; all bits that, in the IPv4 address, follow this IPv4 prefix; some bits of the destination port. 

Looking for a match between an IPv4 address and an IPv4 PREFIX is radically different from looking for a PORT RANGE that contains a given port.


(Incidentally, the same analysis applies AFAIK to MAP-E and MAP-T.) 



2. 4rd isn't concerned with patents EP 2297927 and/or EP 2297927 because address formats are beyond doubt incompatible. 

- In both EP 2297927 and EP 2297928, each IPv6 address constructed from an IPv4 A+P MUST CONTAIN the FULL IPv4 address FOLLOWED BY the port number.
 
- In 4rd, an IPv6 address derived from an IPv4 A+P NEVER contains the FULL IPv4 address FOLLOWED by a port number:

 . The full IPv4 address is always embedded in bits 80-111 of IPv6 addresses, but always followed by a CNP field which has no relation to the port number (Figure 5).

 . With a CE mapping rule, the first 64 bits of the IPv6 address may contain part of the IPv4 address but NEVER the full address. (A CE mapping rule has a Rule-IPv4-prefix length k > 0  because with k = 0 it couldn't be distinguished, by address longest match, from the BR mapping rule whose k must be 0. With k > 0, at most 32 - k bits of IPv4 addresses can be embedded in 4rd IPv6 prefixes.) 
   
 . With the BR mapping rule, no IPv4-address bit is embedded in the first 80 bits of IPv6 addresses (Figure 5).


(Incidentally, the same reasoning doesn't apply to MAP-E and MAP-T because their PSIDs are repeated after embedded IPv4 addresses. Where PSID lengths are 16 bits, which is permitted, IPv6 addresses do contain IPv4 addresses followed by port numbers.)
__________________







2013-04-05 19:53, IETF Secretariat <ietf-ipr@ietf.org> :

> 
> Dear Remi Despres, Reinaldo Penno, Yiu Lee, Gang Chen, Sheng Jiang, Maoke Chen:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "IPv4 Residual
> Deployment via IPv6 - a Stateless Solution (4rd)" (draft-ietf-softwire-4rd) was
> submitted to the IETF Secretariat on 2013-03-20 and has been posted on the "IETF
> Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/2050/). The title of the IPR disclosure is
> "France Telecom's Statement about IPR related to draft-ietf-softwire-4rd-04."");
> 
> The IETF Secretariat
>