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

From: Rémi Després <[email-masked]>
Date: Tue, 9 Apr 2013 17:58:44 +0200

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 <[email-masked]> :

> 
> 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
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 10 Apr 2013 01:15:37 -0400

Hi Remi,
  I just wanted to point out that the IETF will make no determination
about the validity of any particular IPR claim as specified in RFC3979
and derived from the principles established in Section 10 of RFC2026.
Any RFC listed in an ipr disclosure will have a notice added (described
in Section 5 of RFC3979) that will contain a disclaimer of validity.

Thanks
Suresh

On 04/09/2013 11:58 AM, Rémi Després wrote:
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 10 Apr 2013 09:23:06 +0200

> in Section 5 of RFC3979) that will contain a disclaimer of validity.

Thanks, Suresh,

Actually, I am well aware of this.

In my understanding, this justifies that an IPR statement that doesn't concern an RFC (with due understanding of initiators of the statement), should be deleted by its initiators, in good faith, rather than inappropriately listed in the RFC itself.

In this context, whether a 4rd IPv6 address can contain, or not, an IPv4 address followed by a port number is, for example, a simple technical matter on which the WG, and in particular a knowledgeable contributor like Med, is well placed to conclude .

Regards,
RD

---

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Apr 2013 11:51:24 +0200

> In my understanding, this justifies that an IPR statement that doesn't concern an RFC (with due understanding of initiators of the statement), should be deleted by its initiators, in good faith, ra…

Just keep in mind that the entity you're trying to convince is France 
Telecom, not this working group. If France Telecom doesn't find your 
arguments convincing, there's nothing we can do.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Apr 2013 11:53:14 +0200

> in Section 5 of RFC3979) that will contain a disclaimer of validity.

According to that section, the notice will be added to any IETF RFC, 
whether there is any IPR declaration or not. So the content of the 
future 4rd RFC will be unaffected by this.

Simon

---

From: Rémi Després <[email-masked]>
Date: Wed, 10 Apr 2013 12:14:54 +0200

Le 2013-04-10 à 11:51, Simon Perreault <[email-masked]> a écrit :

> Just keep in mind that the entity you're trying to convince is France Telecom, not this working group. If France Telecom doesn't find your arguments convincing, there's nothing we can do.

Well understood.

That's why my analysis is directly addressed to Med, the "Contact Information for the IETF Participant Whose Personal Belief Triggered this Disclosure".

I have confidence in his good faith, well known in the WG, to correct this mistake (or to explain in what my analysis would be wrong).

Cheers,
RD