Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-04.txt

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Jul 2012 18:36:26 +0900

On Mon, Jun 25, 2012 at 4:34 PM, Rémi Després <[email-masked]>wrote:

> Hi, Masanobu-san,
>
> I have to confirm, no surprise, that I object to its BCP status because:
> - it proposes more than just a combination of existing RFCs
>

What does it propose that's not just a combination of existing RFCs? It
seems to me that the document essentially just says "you can build a
service called 464xlat by combining the behaviour specified by these two
RFCs, and choosing these particular values as parameters". It's not
specifying any new behaviour.

> - it has close relationship with subjects discussed in Softwires such as
> MAP and 4rd, without serious examination of this relationship.
>

I don't understand why this would apply differently to a BCP or to an
informational document. Also, I don't understand why this is relevant at
all. The softwires work is attempting to solve a similar problem by
defining new technology, and the approaches don't overlap.

Cheers,
Lorenzo

---

From: Rémi Després <[email-masked]>
Date: Wed, 11 Jul 2012 14:33:23 +0200

Hi, Lorenzo,

Comments about your two mails inline.

2012-07-11 à 11:36, Lorenzo Colitti:

> On Mon, Jun 25, 2012 at 4:34 PM, Rémi Després <[email-masked]> wrote:
> Hi, Masanobu-san,
> 
> What does it propose that's not just a combination of existing RFCs? It seems to me that the document essentially just says "you can build a service called 464xlat by combining the behaviour specified by these two RFCs, and choosing these particular values as parameters". It's not specifying any new behaviour.

(*)
At least two points (both valuable IMHO) specify new behaviors:
- In section 3: << The CLAT does not comply with the sentence "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix." that is described on Section 3.3 in [RFC6052] due to using different IPv6 prefixes for CLAT-side and PLAT-side IPv4 addresses. >>
- There is a request to IANA in section 10.

BCP is therefore inappropriate AFAIK.
Whether Experimental would be better than Informational remains however open AFAIAC.

>  
> - it has close relationship with subjects discussed in Softwires such as MAP and 4rd, without serious examination of this relationship.
> 
> I don't understand why this would apply differently to a BCP or to an informational document. Also, I don't understand why this is relevant at all. The softwires work is attempting to solve a similar problem by defining new technology, and the approaches don't overlap.

Hastily freezing a recommended behavior while a better one is being currently worked on, is in my understanding inappropriate.

In particular, improved transparency to IPv4 null checksums and to DF=1 fragmented packets of RFC 4821 is worth considering (as proposed with the NAT64+ of tools.ietf.org/html/draft-ietf-softwire-4rd-02). 

OTOH, as I said, publishing 4X4XLAT now is IMHO valuable (be it as informational or experimental): it deals with a subject not covered in other IETF documents.

2012-07-11  11:38, Lorenzo Colitti :

> On Tue, Jul 3, 2012 at 5:39 PM, Rémi Després <[email-masked]> wrote:
> A good reason to refuse Informational or Experimental hasn't been seen on this list.
> 
> An informational document is not a standards document.

Neither a BCP AFAIK.

> Thus, it cannot prevent the development of multiple incompatible implementations.

(**)
464XLAT defines a CLAT behavior designed to work with any NAT64, so that AFAIK incompatibility isn't an issue.

> Given that this document describes how to compose existing standards to run a service that requires both customer-side and provider-side components, I'd say interoperability is pretty important if this is to work at all.

(*)and (**) above are relevant here.

The remaining question is while the chairs wouldn't accept an Informational or Experimental status while authors themselves are open to it.

Cheers,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 11 Jul 2012 11:27:25 -0700

On Jul 11, 2012 8:33 AM, "Rémi Després" <[email-masked]> wrote:
>> On Mon, Jun 25, 2012 at 4:34 PM, Rémi Després <[email-masked]
> wrote:
>>>
>>> Hi, Masanobu-san,
>>>
> - In section 3: << The CLAT does not comply with the sentence "Both
IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD
use the same prefix." that is described on Section 3.3 in [RFC6052] due to
using different IPv6 prefixes for CLAT-side and PLAT-side IPv4 addresses. >>
>>> - it has close relationship with subjects discussed in Softwires such
as MAP and 4rd, without serious examination of this relationship.
>
>
> Hastily freezing a recommended behavior while a better one is being
currently worked on, is in my understanding inappropriate.
>
> In particular, improved transparency to IPv4 null checksums and to DF=1
fragmented packets of RFC 4821 is worth considering (as proposed with the
NAT64+ of tools.ietf.org/html/draft-ietf-softwire-4rd-02).

Better?  I thought we resolved long ago to not fall into these types of
unqualified statements.

CB

> OTOH, as I said, publishing 4X4XLAT now is IMHO valuable (be it as
informational or experimental): it deals with a subject not covered in
other IETF documents.
>> On Tue, Jul 3, 2012 at 5:39 PM, Rémi Després <[email-masked]
> wrote:
>>>
>> Given that this document describes how to compose existing standards to
run a service that requires both customer-side and provider-side
components, I'd say interoperability is pretty important if this is to work
at all.
> The remaining question is while the chairs wouldn't accept an
Informational or Experimental status while authors themselves are open to
it.
>
> Cheers,
> RD
>
>
>
>
>>
>> Cheers,
>> Lorenzo
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Jul 2012 07:50:17 +0200

Hi, Cameron,

Please see inline.

> On Jul 11, 2012 8:33 AM, "Rémi Després" <[email-masked]> wrote:
...
> Better? I thought we resolved long ago to not fall into these types of unqualified statements.
> 

Here is, with more details, why my statement to Lorenzo was IMHO worth making:
 
1.
- IPv4 may have fragmented packets (like IPv6)
- RFC 4821 (standard track) recommends that they be sent with DF=1
- RFC 6145 translates IPv6 fragmented packets into IPv4 fragmented packets that have DF=0
=> This conflicts with the objective of RFC 4821.
2.
- In IPv4 UDP datagrams may be without checksum (unlike IPv6)
- RFC 6145 translates IPv4 null-checksum datagrams into a valid-checksum IPv6 datagrams, even if corrupted before translation
=> This introduces a security risk
3.
- A mechanism to avoid these two problems, including in stateful NAT64s if upgraded to this effect, have been identified in Softwire, in a draft having authors from widely different origins. 
- This mechanism has no identified side effect that would introduce service regression.
=> the word "better behavior" is justified. 

If you still object to some of the points above, please explain, preferably after a look at the above-mentioned Softwire draft.

Regards,
RD