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

From: [email-masked]
Date: Mon, 02 Jul 2012 20:45:22 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : 464XLAT: Combination of Stateful and Stateless Translation
	Author(s)       : Masataka Mawatari
                          Masanobu Kawashima
                          Cameron Byrne
	Filename        : draft-ietf-v6ops-464xlat-05.txt
	Pages           : 19
	Date            : 2012-07-02

Abstract:
   This document describes an architecture (464XLAT) for providing
   limited IPv4 connectivity across an IPv6-only network by combining
   existing and well-known stateful protocol translation RFC 6146 in the
   core and stateless protocol translation RFC 6145 at the edge. 464XLAT
   is a simple and scalable technique to quickly deploy limited IPv4
   access service to IPv6-only edge networks without encapsulation.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-05

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Masanobu Kawashima <[email-masked]>
Date: Tue, 3 Jul 2012 12:49:48 +0900

Hi all,

We have published draft-ietf-v6ops-464xlat-05.
We think this version is enough to do WGLC.

Changes are:

 - adding the issues related to mobile network in the section
     of "Wireless 3GPP Network Applicability".

 - adding [TS23.203] in the section of "Informative References".

 - adding Tom-san and Jouni-san to acknowledgements.

All comments are welcome.

Regards,
Masanobu

>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

========================================
 NEC AccessTechnica, Ltd.               
 Product Development Department         
 Masanobu Kawashima                     
 [email-masked]               
 http://www.necat.co.jp/                
========================================

---

From: Rémi Després <[email-masked]>
Date: Tue, 3 Jul 2012 10:39:27 +0200

> - adding Tom-san and Jouni-san to acknowledgements.

But again ignoring http://www.ietf.org/mail-archive/web/v6ops/current/msg13314.html

Support for to WGLC if changed to Informational (or Experimental).
But objection to WGLC is confirmed if BCP is the maintained status.
A good reason to refuse Informational or Experimental hasn't been seen on this list.

Regards,
RD

---

From: Joe Touch <[email-masked]>
Date: Fri, 06 Jul 2012 15:46:15 -0700

This doc relies on RFC 6145, which has a few key problems:

1. it sets IPv4 ID=0 when IPv6 lacks a frag header

     that will hopefully be possible after ipv4-id-update is final
     (if it does proceed as intended) but isn't true now

2. copying the low 16 bits of the IPv6 ID field to the IPv4 ID field is 
invalid
     that field might not follow the ID uniqueness criteria of IPv4

3. the system assumes IPv4 can reassemble 1280 byte packets
     but only 576 can be assumed

I've pointed these out elsewhere, but they need to be resolved before 
any doc that relies on it can proceed, IMO.

Joe

---

From: MAWATARI Masataka <[email-masked]>
Date: Mon, 09 Jul 2012 10:39:38 +0900

Dear Joe-san,

Thank you very much for your comments and information about
ipv4-id-update.

Translation does not have full-transparency and then 464XLAT
includes issues based on that as you said.

464XLAT is a method that provide limited IPv4 connectivity using
translation.  We authors write that in the section of abstract.

Kind Regards,
Masataka MAWATARI

* On Fri, 06 Jul 2012 15:46:15 -0700

---

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

> A good reason to refuse Informational or Experimental hasn't been seen on

An informational document is not a standards document. Thus, it cannot
prevent the development of multiple incompatible implementations.

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.

Cheers,
Lorenzo