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

From: [email-masked]
Date: Sun, 19 Aug 2012 23:04:08 -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-07.txt
	Pages           : 19
	Date            : 2012-08-19

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

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

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

---

From: Masanobu Kawashima <[email-masked]>
Date: Mon, 20 Aug 2012 15:08:39 +0900

Hi all,

Thank you for many comments.

I've published draft-ietf-v6ops-464xlat-07.
We authors considered all comments from v6ops community.
Please check Diff1 or Diff2 in tools.ietf.org.

BTW, can we start WGLC by this version?

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: t.petch <[email-masked]>
Date: Mon, 20 Aug 2012 10:36:47 +0100

----- Original Message -----
From: "Masanobu Kawashima" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 20, 2012 7:08 AM

> Please check Diff1 or Diff2 in tools.ietf.org.

Tweak, tweak.  Trouble is, every time a new version appears I read it
and generate comments I have not made before (please stop issuing new
versions:-).

This time, and thank you for incorporating my previous comments, it is

s.7.2.  " The vast majority of mobile networks are compliant to
Pre-Release 9"

Does that mean Pre-Release 9 or later, or is this specific to
Pre-Release 9?

And given that this RFC will be around for decades and is likely to be
read for years, I think that this statement needs qualifying, such as

"At the time of writing, in August 2012, the vast majority of mobile
networks ..."

Tom Petch

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Aug 2012 16:32:51 +0200

Hi, Masanobu-san,

Thanks for the latest progress, in particular the clarification of section 8.3.2 on what is achieved with the IANA-assigned interface ID.

With Tom's suggestion and (1) and (2) below taken care of, the draft is AFAIAC ready for WGLC.

(1)  A further progress on the 464XLAT interface ID is possible by proposing in Section 11 only one value (02-00-5E-10-00-00-00-00, the value used in the appendix). 

(Hesitation between a "reserved" or "available" range of RFC5342 is AFAIK historical, due to something I had written and never updated. Fortunately, it isn't too late.) 

(2) In 8.3.2, instead of 
"If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of the implementation, the CLAT may use a dedicated IANA assigned EUI-64 ID ...", 
proposed text: 
"The CLAT SHOULD use the reserved  IANA assigned EUI-64 ID of Section 11 ..." 

Rationale is simplicity. Even if the CLAT node can do ND proxy, it has to be decided which interface ID it excludes, and this excluded ID may be in addition to that of the node at its IPv6 WAN interface. Without explaining this, the specification would be incomplete. Once there is a reserved ID, using it is trivial.

(3) In 8.1, just a minor suggestion:
After "The IPv6 address format in 464XLAT is defined in Section 2.2 of [RFC6052]" add " completed, if applicable according to Section 8.3.2, with the 464XLAT interface ID of Section 11." 

Regards,
RD