Subject: [v6ops] draft-ietf-v6ops-464xlat

From: Ray Hunter <[email-masked]>
Date: Mon, 14 May 2012 15:48:59 +0200

I have read this draft.

I do not pretend to be an expert in this particular field so I'm 
reviewing it more from a general network operator viewpoint.

Question 1:

If a dual stack IPv4+IPv6 client node is communicating to an IPv4 only 
server, is the translation path native IPv4 on the client -> 464 -> 
native IPv4 on the server preferable over the translation path native 
IPv6 on the client -> NAT64 + DNS64 -> native IPv4 on the server?

That may come down to 2 things: preferable in that it's technically 
better, or not preferable in that the operator wants to discourage use 
of IPv4.

Question 2:

If this is true, how do you handle synthesised AAAA records generated by 
DNS64 on the PLAT that are needed for an IPv6 only client to communicate 
with a IPv4 only server, but which would be disruptive to a dual stack 
client communicating to the same IPv4 server? Re: Section 6.3.2 of 
RFC6147. Would the CLAT have to selectively filter these synthesised 
AAAA answers out, depending if it detected that the end client was 
single or dual stack?

Question 3:

ref /It is also possible to provide single IPv4/IPv6 translation 
service, which will be needed in the future case of IPv6-only servers 
and peers to be reached from legacy IPv4-only hosts./

Likewise, would the CLAT or PLAT have to perform any special DNS 
translation to handle an IPv4 only client communicating with an IPv6 
only server (DNS46??)

Question 4:

Would it also be possible to transform IPv4 to IPv6 using RFC6145 for 
transport across the IPv6 only edge network, and then perform the 
stateless inverse transform of RFC6145 to get back your original IPv4 
packet at the physical location of the PLAT (with private IPv4 source 
address) before sending this facsimile of the original packet into a 
standard stateful NAT44 device or other translation device? This would 
effectively be a two step NAT64.

1st motivation: Previous experience with Ethernet -> FDDI translation 
bridging suggests to me it's relatively easy to translate outer 
frame/packet headers on a symmetrical path like client -> Ethernet -> 
FDDI -> Ethernet -> server , but very difficult to catch all the 
protocol layer violations and name leaks in devices that perform single 
translations like client -> Ethernet -> FDDI -> server. 2nd Motivation: 
Stateful NAT44 devices are already abundant, cheap, and well understood. 
3rd motivation: you could deploy an ALG, proxy, or other higher layer 
alternative at the PLAT location if NAT44 didn't work out for some 
specific protocols.

Thanks!
RayH

Nits & Spelling
===========

Section 1.

s/deploy limited IPv4 access service to mobile/deploy a limited IPv4 
access service to mobile/

s/The 464XLAT IPv4 service is limited to application that function/The 
464XLAT IPv4 service is limited to applications that function/

s/in a client server model/in a client server model where the server has 
been assigned a globally unique IPv4 address,/

Section 3.

s/ CLAT SHOULD perform router function to facilitate packets forwarding 
through the stateless translation even if it is an end-node/ CLAT SHOULD 
be combined with a CPE router function to ensure packets are forwarded 
through the stateless translation even if the CLAT is running on an 
end-node/

Section 4.

s/crucial for enabling the IPv4-only applications/crucial for enabling 
IPv4-only applications/

s/Unlike other transition architectures associated with tunneling 
or/Unlike other transition architectures associated with tunneling or A&P/

/If the IXP or another provider operates the PLAT/If the IXP (Internet 
Exchange Point ) or another ISP provider operates the PLAT/

Section 6.

s/Incidentally, Japan Internet Exchange(JPIX) is providing 464XLAT trial 
service since July 2010.  In addition to this, the effectiveness of 
464XLAT was confirmed in the WIDE camp Spring 2012.  The result is 
described in [I-D.hazeyama-widecamp-ipv6-only-experience].//

Suggest removing from BCP document.

s/Since there are 2 PDPs required to support 2 address families/Since a 
dedicated PDP is required to support each of the IPv4 and IPv6 address 
families in Pre-Release 9 3GPP standards/

s/Connections sourced from the IPv4 interface are immediately routed to 
the CLAT function and passed to the IPv6-only mobile network, destine to 
the PLAT.  In summary, the UE has the CLAT function that does a 
stateless translation [RFC6145], but only when required. The mobile 
network has a PLAT that does stateful translation [RFC6146]./Connections 
sourced from the IPv4 interface are immediately routed to the CLAT 
function and then transported via the IPv6-only mobile network to the 
PLAT.  In summary, the UE implements the CLAT function, providing 
stateless translation of IPv4 traffic [RFC6145], but only when required. 
The mobile network implements a PLAT, providing stateful translation of 
IPv6 traffic [RFC6146], but again only when required./

Section 7.

s/consume gateway function/consumer premises equipment gateway function/

Section 7.5.

s/ In another cases where/ In other cases where/

Section 7.6.

s/not have dedicated IPv6 prefix/not have a dedicated IPv6 prefix/

Section 7.7.

s/The router with CLAT function SHOULD provide common router services 
such as DHCP of [RFC1918] addresses , DHCPv6, and DNS service/A router 
implementing a CLAT function SHOULD also provide common CPE router 
functions, such as DHCP of [RFC1918] addresses, DHCPv6, and DNS services/

s/translation of DNS request/translation of DNS requests/

Section 7.8.
Suggest this is pretty irrelevant. The introduction already states that 
inbound traffic is not supported.

Section 8.
s/Internet access provider/Internet Service Provider/  [for consistency]

s/without any deep packet inspection for processing the inner 
IPv4/without performing deep packet inspection that processes the inner 
IPv4/

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 14 May 2012 12:32:48 -0700

Ray,

Thanks for the detailed review.  In line.

On Mon, May 14, 2012 at 6:48 AM, Ray Hunter <[email-masked]> wrote:
> I have read this draft.
>
> I do not pretend to be an expert in this particular field so I'm reviewing
> it more from a general network operator viewpoint.
>
> Question 1:
>
> server, is the translation path native IPv4 on the client -> 464 -> native
> IPv4 on the server preferable over the translation path native IPv6 on the
> client -> NAT64 + DNS64 -> native IPv4 on the server?
>
> That may come down to 2 things: preferable in that it's technically better,
> or not preferable in that the operator wants to discourage use of IPv4.
>

If the client node is dual-stack the translation path will be dictated
by the address family choice of the client.

464XLAT CLAT presents both address families as available.  Most
clients prefer IPv6 when available.  With DNS64 in the network, IPv6 /
AAAA is always available when asked for.

> client communicating to the same IPv4 server? Re: Section 6.3.2 of RFC6147.
> Would the CLAT have to selectively filter these synthesised AAAA answers
> out, depending if it detected that the end client was single or dual stack?
>

464XLAT is an architecture for an IPv6-only access network, and
therefore Section 6.3.2 of RFC6147 does not apply.

The CLAT does not do any DNS filtering.

The 464 architecture treats traffic as defined here
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-03#section-7.3

> Question 3:
>
> ref /It is also possible to provide single IPv4/IPv6 translation service,
> which will be needed in the future case of IPv6-only servers and peers to be
> reached from legacy IPv4-only hosts./
>
> Likewise, would the CLAT or PLAT have to perform any special DNS translation
> to handle an IPv4 only client communicating with an IPv6 only server
> (DNS46??)
>

No.

> transport across the IPv6 only edge network, and then perform the stateless
> inverse transform of RFC6145 to get back your original IPv4 packet at the
> physical location of the PLAT (with private IPv4 source address) before
> sending this facsimile of the original packet into a standard stateful NAT44
> device or other translation device? This would effectively be a two step
> NAT64.
>

Yes, but that is not 464XLAT.  464XLAT is 6145 at the CLAT and 6146 at the PLAT.

> bridging suggests to me it's relatively easy to translate outer frame/packet
> headers on a symmetrical path like client -> Ethernet -> FDDI -> Ethernet ->
> server , but very difficult to catch all the protocol layer violations and
> name leaks in devices that perform single translations like client ->
> Ethernet -> FDDI -> server. 2nd Motivation: Stateful NAT44 devices are
> already abundant, cheap, and well understood. 3rd motivation: you could
> deploy an ALG, proxy, or other higher layer alternative at the PLAT location
> if NAT44 didn't work out for some specific protocols.
>

I don't align with those motivations.

Thanks again for the review.

CB

> Thanks!
> RayH
>
>
> Nits & Spelling
> ===========
>
> Section 1.
>
> s/deploy limited IPv4 access service to mobile/deploy a limited IPv4 access
> service to mobile/
>
> through the stateless translation even if it is an end-node/ CLAT SHOULD be
> combined with a CPE router function to ensure packets are forwarded through
> the stateless translation even if the CLAT is running on an end-node/
>
> Section 4.
>
> s/Unlike other transition architectures associated with tunneling or/Unlike
> other transition architectures associated with tunneling or A&P/
>
> service since July 2010.  In addition to this, the effectiveness of 464XLAT
> was confirmed in the WIDE camp Spring 2012.  The result is described in
> [I-D.hazeyama-widecamp-ipv6-only-experience].//
>
> s/Connections sourced from the IPv4 interface are immediately routed to the
> CLAT function and passed to the IPv6-only mobile network, destine to the
> PLAT.  In summary, the UE has the CLAT function that does a stateless
> translation [RFC6145], but only when required. The mobile network has a PLAT
> that does stateful translation [RFC6146]./Connections sourced from the IPv4
> interface are immediately routed to the CLAT function and then transported
> via the IPv6-only mobile network to the PLAT.  In summary, the UE implements
> the CLAT function, providing stateless translation of IPv4 traffic
> [RFC6145], but only when required. The mobile network implements a PLAT,
> providing stateful translation of IPv6 traffic [RFC6146], but again only
> when required./
>
>
> Section 7.
>
> s/The router with CLAT function SHOULD provide common router services such
> as DHCP of [RFC1918] addresses , DHCPv6, and DNS service/A router
> s/without any deep packet inspection for processing the inner IPv4/without
> performing deep packet inspection that processes the inner IPv4/
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ray Hunter <[email-masked]>
Date: Mon, 14 May 2012 22:16:49 +0200

Thanks. Couple of follow ups inline if I may.
> Cameron Byrne <mailto:[email-masked]>
> 14 May 2012 21:32
> Ray,
>
> On Mon, May 14, 2012 at 6:48 AM, Ray Hunter<[email-masked]>  wrote:
>> I have read this draft.
>>
Yep. Got that already.

What I wanted to know was if you expected 464 to produce less 
translation errors and operational problems than NAT64+DNS64, so could 
an operator force use of 464 on dual stack hosts to IPv4 servers by 
filtering out the synthesised AAAA records of DNS64 for dual stacked 
hosts, whilst passing them through for single IPv6 only hosts?

But I guess that's implementation dependent, and out of scope of your 
architecture.
> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-03#section-7.3
Ack.
>> to handle an IPv4 only client communicating with an IPv6 only server
Don't understand this. rfc6145 does not include any DNS content 
translation AFAIK.

How would an IPv4 only host be able to resolve the to-be-translated IPv4 
address for a connection to an IPv6 only server that only had a AAAA 
record, and no native A record?
> Yes, but that is not 464XLAT.  464XLAT is 6145 at the CLAT and 6146 at the PLAT.
Ack.
> Thanks again for the review.
Ack.

<snip>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 14 May 2012 15:58:40 -0500

Ray,

> record, and no native A record?

I don't think that this use-case is covered by 464XLAT, but Is the
v6-only server realistic yet? 

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ray Hunter
> Sent: Monday, May 14, 2012 4:17 PM
> To: Cameron Byrne
> Cc: [email-masked] WG; [email-masked]
> Subject: Re: [v6ops] draft-ietf-v6ops-464xlat
> 
reviewing
> >> That may come down to 2 things: preferable in that it's technically
better,
> RFC6147.
service,
> >> which will be needed in the future case of IPv6-only servers and
peers to
> be
> translation
> stateless
> >> sending this facsimile of the original packet into a standard
stateful
> NAT44
> > Yes, but that is not 464XLAT.  464XLAT is 6145 at the CLAT and 6146
at the
> PLAT.
> frame/packet
> >> headers on a symmetrical path like client ->  Ethernet ->  FDDI ->
Ethernet
> ->

---

From: Ray Hunter <[email-masked]>
Date: Mon, 14 May 2012 23:16:57 +0200

> Rajiv Asati (rajiva) <mailto:[email-masked]>
> 14 May 2012 22:58
> Ray,
>
Don't know.

I was just triggered by the following sentence in the 464XLAT ID, which 
is why I asked the question:

/It is also possible to provide single IPv4/IPv6 translation service, 
which will be needed in the future case of IPv6-only servers and peers 
to be reached from legacy IPv4-only hosts./

regards,
RayH

---

From: Rémi Després <[email-masked]>
Date: Tue, 15 May 2012 09:36:13 +0200

Masataka-san, Masanobu-san, Cameron,

1.
Could you please clarify your intention?

Privately, you justified your lack of interest for improvements I proposed by your wish to publish the draft as is, planing for this to have it back to *informational* rather than BCP.
If this is the case, can you please confirm here?

If not, I guess I should send to the WG detailed amendments proposed to you for the BCP to be acceptable AFAIAC.

2.
2012-05-14  23:16, Ray Hunter:
> I was just triggered by the following sentence in the 464XLAT ID, which is why I asked the question:
> 
> /It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts./

As already said, this sentence becomes understandable if it is noted that 464XLAT can be combined with RFC 6535.
(RFC 6535 is the standard track specification for connectivity from IPv4-only applications to IPv6-only servers).
Without this, the sentence should IMHO be deleted.

Regards,
RD

---

From: MAWATARI Masataka <[email-masked]>
Date: Wed, 16 May 2012 05:23:46 +0900

Dear Remi-san and all,

We appreciate your comments.

1.
There were some comments about deleting dedicated IPv6 prefix model
without NAT44 from the 464XLAT document on v6ops mailing list.

But, we, 464XLAT co-authors, would like to keep the dedicated IPv6
prefix model without NAT44 on the 464XLAT document.

Our beliefs are simple as below.

   - We insist that we should eliminate implement complexity on CPE
     and reduce the cost (memory resources on CPE, operation cost
     (troubleshooting, user support)) for IPv4 long life during a
     period of transition from IPv4 to IPv6 as far as possible.

   - 464XLAT using a dedicated IPv6 prefix can do that instead of
     assigning a dedicated IPv6 prefix for translation.

We would not like to write specific descriptions for keeping
selectivity of operator's priority. So we think we should write
2 models (dedicated IPv6 prefix and no dedicated IPv6 prefix).
Honestly, we do not care about the document category. We think
that is depending on v6ops members and chairs.

2.
We will add following sentence.
---
By combining 464XLAT with BIH [RFC6535], it is also possible to
provide single IPv4/IPv6 translation service, which will be needed in
the future case of IPv6-only servers and peers to be reached from
legacy IPv4-only hosts across IPv6-only networks.
---

If we have any missing points, please let me know.

Kind Regards,
Masataka MAWATARI

* On Tue, 15 May 2012 09:36:13 +0200

---

From: Rémi Després <[email-masked]>
Date: Wed, 16 May 2012 09:35:33 +0200

Le 2012-05-15 à 22:23, MAWATARI Masataka a écrit :

> Honestly, we do not care about the document category.

> We think

If the proposed simplification based on on a CLAT well-known interface ID is not included, I personally object to BCP status, but have no objection against Informational (the originally proposed status).

> legacy IPv4-only hosts across IPv6-only networks.

A useful clarification IMHO.
Thanks.

Regards,
RD

---

From: Ray Hunter <[email-masked]>
Date: Wed, 16 May 2012 09:57:36 +0200

Thanks Masataka-san.

The pointer from Remi and yourself to RFC6535 answered my question and 
removed my confusion on DNS A record synthesis.

But RFC6535 will NOT help with legacy IPv4 only *hosts* IMHO

RFC6535 provides the necessary locally synthesised A record within the 
API to support certain legacy IPv4 only *applications*, only on the 
client side, only for applications that can traverse NAT, and only for 
ones that use DNS for name resolution. The synthesised A record never 
appears on the wire.

All hosts will still eventually have to speak native IPv6 on the wire if 
they want to enjoy universal connectivity.

It may seem like a small thing to the WG, but raising any expectations 
that legacy IPv4 hosts and applications can continue to work as-is 
forever without any changes (due to the widespread deployment of magic 
translators within the Internet infrastructure) makes many of my clients 
doubt whether they should invest in IPv6 at all.

Respectfully suggest the following text:

By combining 464XLAT with BIH [RFC6535], it is also possible to
provide a single step IPv4/IPv6 translation service, which may be needed in
the future so that IPv6-only servers and peers can be reached across
IPv6-only networks  from a limited subset of legacy IPv4-only applications.

regards,
RayH

MAWATARI Masataka wrote:
> * Remi Despres<[email-masked]>  wrote:
>
>>>> Rajiv Asati (rajiva)<mailto:[email-masked]>
>>>> 14 May 2012 22:58
>>>> Ray,
>>>>

---

From: jouni korhonen <[email-masked]>
Date: Wed, 16 May 2012 13:59:07 +0300

Hi,

I got few comments on the draft -03.. mainly editorial.

o Sections 3. and 6.2. first paragraphs could add a reference to [RFC6459],
  since it is already in the references section but never used in the main
  text. My proposals:

  Section 3:
       ...
       translation.  This is especially cost-effective in wireless 3GPP
       GSM and UMTS networks that would otherwise require two separate
       PDP connections to support IPv4 and IPv6 [RFC6459].

  Section 6.2:
   The vast majority of mobile wireless networks are compliant to Pre-
   Release 9 3GPP standards.  In Pre-Release 9 3GPP networks, GSM and
   UMTS networks must signal and support both IPv4 and IPv6 PDP
   attachments to access IPv4 and IPv6 network destinations [RFC6459].
   ...

o Section 3 could add a reference to TS23.203 for PCC.

o Section 6.2 could also mention that each PDP connection also
  equals to a RAB, which is indeed costly when it comes to support
  for parallel context over the radio.

o Section 7.5 talks about the case where there is no dedicated 
  translation prefix. I would not say "will do NAT44.." there,
  rather "can do NAT44.." This is imho an implementation choice,
  for example, inside the UE that has to serve only a single IPv4
  address.

o Same as above for Section 7.6

o Section 7.5 or Section 6.2 could state for 3G case that when DHCPv6-PD
  is not available opening a second IPv6 PDP Connection for obtaining a
  dedicated translation prefix is not recommended. Rather stick with a
  single prefix model..

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 16 May 2012 14:54:00 -0500

On Wed, May 16, 2012 at 5:59 AM, jouni korhonen <[email-masked]> wrote:
>  dedicated translation prefix is not recommended.

> Rather stick with a

Why?

Because of PD-exclude?

I don't see any reason for this restriction.

We discussed single prefix issue with Maglione Roberta.
There is nothing like "single prefix is required".

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Thu, 17 May 2012 00:38:41 +0300

>>  dedicated translation prefix is not recommended.

Read above "..when DHCPv6-PD is not available.."

> I don't see any reason for this restriction.

Recommendation != restriction. One reasoning for a recommendations
was given above.

Opening parallel contexts, even if they all are IPv6 only consume
resources (including stuff like licenses, per UE radio scheduler
slots etc.) That can be (and for quite a few folks is) an issue
to take into account.

- Jouni

---

From: MAWATARI Masataka <[email-masked]>
Date: Fri, 18 May 2012 14:44:11 +0900

Dear v6ops,

Sorry for delay.
We, 464XLAT co-authors, had discussed about following comments.

---
---

IANA's EUI-64 ID is a reasonable solution.

We will write 2 models ("no dedicated IPv6 prefix model by using
NAT44 with IANA's EUI-64 ID" and "dedicated IPv6 prefix model
without NAT44") on the 464XLAT document as a BCP text.

We are thinking that "no dedicated IPv6 prefix model by using
NAT44 with IANA's EUI-64 ID" is appropriate for the mobile services
that can not utilize DHCPv6-PD yet and "dedicated IPv6 prefix model
without NAT44" is appropriate for the service that can utilize
DHCPv6-PD (e.g. most of wireline services).

However, using NAT44 with IANA's EUI-64 ID is not comply RFC 6145.
So we would like to write the requirement language as a "MAY".
It is for keeping selectivity of operator's priority.

If we have any missing points, please let us know.

Kind Regards,
Masataka MAWATARI

* On Wed, 16 May 2012 09:35:33 +0200
* Remi Despres <[email-masked]> wrote:

> Le 2012-05-15 a 22:23, MAWATARI Masataka a ecrit :
> 
> > Dear Remi-san and all,
> >

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 May 2012 15:35:16 +0900

> It is for keeping selectivity of operator's priority.

Hmm. Can you explain a bit more how that conflicts with RFC 6145?

---

From: Admin <[email-masked]>
Date: Fri, 18 May 2012 08:42:49 +0200

2012-05-18  07:44, MAWATARI :

> that can not utilize DHCPv6-PD yet

> and "dedicated IPv6 prefix model

Don't understand why the IANA's EUI-64 ID wouldn't be appropriate for this case too.
Could you explain?

> However, using NAT44 with IANA's EUI-64 ID is not comply RFC 6145.

Don't see where RFC 6145 would conflict.
Can you be more precise?

> If we have any missing points, please let us know.

Clarifications on the above are IMHO needed.

Regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 May 2012 15:45:29 +0900

> Don't understand why the IANA's EUI-64 ID wouldn't be appropriate for this

This model works by statelessly mapping the IPv4 addresses of CLAT clients
into IPv6 addresses of the given prefix. So it obviously doesn't use a
fixed interface ID.

---

From: Admin <[email-masked]>
Date: Fri, 18 May 2012 08:59:17 +0200

Le 18 mai 2012 à 08:45:29, Lorenzo Colitti a écrit :

> This model works by statelessly mapping the IPv4 addresses of CLAT clients into IPv6 addresses of the given prefix. So it obviously doesn't use a fixed interface ID.

This isn't an answer to my question: "why using the IANA's EUI + NAT44 model wouldn't work also if DHCPv6 is operational"?

RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 May 2012 16:19:33 +0900

On Fri, May 18, 2012 at 3:59 PM, Admin <[email-masked]> wrote:

> This isn't an answer to my question: "why using the IANA's EUI + NAT44
> model wouldn't work also if DHCPv6 is operational"?
>

I believe that the reason is to support the use case of a shared,
large-scale CLAT that serves a large number of users, possibly from many
different operators. In that case, the NAT444 is a significant bottleneck
compared to stateless operation.

---

From: Masanobu Kawashima <[email-masked]>
Date: Fri, 18 May 2012 18:33:41 +0900

Hi Remi,

Thank you for your comment.

>This isn't an answer to my question: "why using the IANA's EUI +
> NAT44 model wouldn't work also if DHCPv6 is operational"?

I think that it would work even if DHCPv6-PD is operational.
However, using the IANA's EUI + NAT44 model does not comply
the following part of RFC6145.

Quote of section 4.1. in RFC6145.

"Translating IPv4 Headers into IPv6 Headers"

(snip)

   Source Address:  The IPv4-converted address derived from the IPv4
      source address per [RFC6052], Section 2.3.

      If the translator gets an illegal source address (e.g., 0.0.0.0,
      127.0.0.1, etc.), the translator SHOULD silently drop the packet
      (as discussed in Section 5.3.7 of [RFC1812]).

Addition to this, some operators or implementors will choose
dedicated IPv6 prefix model in order to avoid operational difficulty
and implementation complexity.

Therefore, we need two models.

I prefer simple combination with RFC6145 and RFC6146.
That is our essential motivation.

Regards,
Masanobu

>
>Le 18 mai 2012 08:45:29, Lorenzo Colitti a 馗rit :
>

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

---

From: Admin <[email-masked]>
Date: Fri, 18 May 2012 14:54:22 +0200

Le 18 mai 2012 à 09:19:33, Lorenzo Colitti a écrit :

> I believe that the reason is to support the use case of a shared, large-scale CLAT that serves a large number of users, possibly from many different operators. In that case, the NAT444 is a significant bottleneck compared to stateless operation.

Documenting a little more one configuration you (or they) have in mind would be useful.
Any justification for two solutions instead of one should be well understood. 

In the draft, a CLAT "has also IPv6 router function that can forward IPv6 packet for IPv6 hosts in end-user network". The CLAT you refer to doesn't seem to be in an end-user network.

RD

---

From: Admin <[email-masked]>
Date: Fri, 18 May 2012 16:03:08 +0200

> and implementation complexity.

Not understood where IANA's CLAT IID would introduce "operational difficulty and implementation complexity" (in my understanding, negligible implementation difference, and simpler operation with the IANA CLAT IID).

Documenting at least one configuration where you this to apply would be clarifying.

RD

---

From: GangChen <[email-masked]>
Date: Sat, 19 May 2012 00:28:59 +0800

>       (as discussed in Section 5.3.7 of [RFC1812]).

When IANA IID was adopted in the non-DHCP-PD case, two benefits here.
1) Avoiding proxy CLAT address
2) 464xlat traffic identifiable

When the network supports DHCP-PD, it may still remain second benefit.
Whereas it may not fully comply with RFC6145.

I saw the benefits, however it should document such process for
illegal source address.

Does the clarification help?

Gang

>>> This model works by statelessly mapping the IPv4 addresses of CLAT
>>> clients into IPv6 addresses of the given prefix. So it obviously doesn't
>>> use a fixed interface ID.
>>

---

From: MAWATARI Masataka <[email-masked]>
Date: Sat, 19 May 2012 11:28:26 +0900

Dear Remi-san and all,

Thank you for your comments.

We, 464XLAT co-authors, do not reject the benefit of using NAT44
with IANA's EUI-64 ID.  Please correct this misinterpretation.

But, we do not understand that you stick with describing only one
model (no dedicated IPv6 prefix model by using NAT44 with IANA's
EUI-64 ID) on 464XLAT document. Sorry, if I'm wrong about this point.

Excuse me for writing again, 464XLAT co-authors' belief about
describing 2 models on 464XLAT document is as below.
http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html

Of course, we understood BIH even now.

Kind Regards,
Masataka MAWATARI

* On Fri, 18 May 2012 16:03:08 +0200
* Admin <[email-masked]> wrote:

> Not understood where IANA's CLAT IID would introduce "operational difficulty
> and implementation complexity" (in my understanding, negligible implementation
> difference, and simpler operation with the IANA CLAT IID).
>

---

From: Admin <[email-masked]>
Date: Sat, 19 May 2012 08:52:56 +0200

Mawartari-san, Masanobu-san,

2012-05-19  04:28:26, MAWATARI Masataka:

> with IANA's EUI-64 ID.  

Well understood.
Thanks.

> Please correct this misinterpretation.

No need, see above.

> EUI-64 ID) on 464XLAT document.

1.
I have, as I said, no objection to a publication with the two models if status is Informational.

2.
Reasons why, at least as long as CLAT nodes are CPEs, the CLAT single address model is IMHO sufficient in a BCP are:
- Doubt that vendors would market new CPEs unable to support NAT44. 
- With that, CLATs can work with ordinary NAT64s without needing more than their ordinary IPv6 prefixes, which is simpler.

=> If BCP is the desired status, more explanation would be needed AFAIAC. 

Regards,
RD

> Sorry, if I'm wrong about this point.
>

---

From: Admin <[email-masked]>
Date: Sat, 19 May 2012 09:32:33 +0200

Masanobu-san,

Thank you for the explanation below.
Formally, you are right: RFC6145 doesn't cover the case where there is only one IPv4 address on the IPv4 side, and where therefore a fixed IPv6 address, non IPv4 translated, can be used.

OTOH, RFC 6052 says, about Stateless translation "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix". Using different IPv6 prefixes for customer-side and Internbet-side IPv4 addresses would introduce an exception to this rule, with the need to explain.

The IANA EUI-64 interface ID remains IMHO worth using, at least when CLAT nodes contain NAT44s.

Regards,
RD

>      source address per [RFC6052], Section 2.3.

This case is however useful since it permits the CLAT model to apply with nothing more than

---

From: t.petch <[email-masked]>
Date: Thu, 24 May 2012 17:34:22 +0100

I would like to see this published, regardless of status, but to think
that it needs more work before it is ready for WGLC.  It is just too
hard to follow.  When I supported its adoption by v6ops, I was expecting
that it would be hammered into shape but that has not happened.

It contains the detail but lacks the overview - framework, architecture
or what, I do not mind, but it is that level of description that it
lacks.  Rather, the first four sections read like marketing, this is a
great idea, you must buy it; err, no, tell me what it is, not the how or
why, and I will decide whether or not to buy it.

The description only starts at section 5 with a diagram, but this is a
diagram that is worth minus one thousand words - if this is 464, then
why is the first line a v6  address - that makes it 664!  And something
you do not explain.

The terminology too seems ill-chosen. For example, clauses such as
" limited to application
   that function in a client server model and is not fit for IPv4 peer-
   to-peer communication or inbound IPv4 connections."
does not impart understanding.  Of course there is an inbound IPv4
connection, your diagrams all show that.  What I reverse-engineer from
the I-D, is that the destination IP address used to establish the
connection MUST be a global IPv4 address.  Which is a much more specific
limitation.

So let's have an overview in section one and then see if the rest of it
still makes sense.

Tom Petch

---

From: MAWATARI Masataka <[email-masked]>
Date: Tue, 29 May 2012 13:50:03 +0900

Dear Remi-san and all,

We appreciate your every comments about 464XLAT.

We will add that the CLAT on 464XLAT architecture does not comply
with "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6
addresses SHOULD use the same prefix." that is described on Section
3.3. in RFC 6052.

And about document's category, we do not care about the document's
category as we have told once. The reason that we changed category
from Informational to BCP is due to v6ops chairs' suggestion. If
v6ops chairs say a request to change from BCP to Informational, we
will defer to that.

In case of keeping present category, although we don't know whether
you are going to like or not, we would like to propose you.

What do you think about splitting text of "no dedicated IPv6 prefix
model by using NAT44 with IANA's EUI-64 ID" for mobile service (3G,
LTE, etc.) that does not utilize DHCPv6-PD yet and "dedicated IPv6
prefix model" for wireline service that utilize DHCPv6-PD as a
convenient function.

This text is completely splitted by service applicability (moblie
and wireline). This is hard to cause some confusions in audiences
of 464XLAT document.

We really understood your thoughts, we can save operation and
deployment cost for IPv4 long-life support by using dedicated IPv6
prefix.

This is a antinomy between dedicated IPv6 prefix is required and
not required. We understood this. So we are thinking that we
would like to describe the 2 models.

Kind Regards,
Masataka MAWATARI

* On Sat, 19 May 2012 09:32:33 +0200

---

From: MAWATARI Masataka <[email-masked]>
Date: Tue, 29 May 2012 13:54:58 +0900

Dear Tom-san,

I understood your thoughts.
I will polish again the diagram on Section 5 and the overview by
adding the explanations.

The IPv6 host on the diagram on Section 5.1 shows that a IPv6 host
can reach the other IPv6 hosts on the Internet via no translation.
This means that the CPE can not only have the function of CLAT but
also the function of IPv6 native router for IPv6 native traffic.

And the 464XLAT architecture provides limited IPv4 service as you
understand. This is true due to hub-and-spoke model using stateful
translation.

Kind Regards,
Masataka MAWATARI

* On Thu, 24 May 2012 17:34:22 +0100

---

From: Rémi Després <[email-masked]>
Date: Tue, 29 May 2012 17:13:10 +0200

Masataka-san,
Please see inline.

> v6ops chairs say a request to change from BCP to Informational, we

I don't expect the chair would object to your returning to the status you originally proposed, especially since it permits document publication without careful comparison with alternative designs discussed in Softwires.

Your announcing that you plan to re-issue the document as Informational would therefore be appreciated.
AFAIAC, it would close this thread of discussion once and for all.

Besides, if BCP remains the target, I agree with Tom Petch that substantial clarification would be needed (overview, framework, architecture, whatever better describes applicability). 

> would like to describe the 2 models.

In the wireline case with an ISP NAT64, I don't see why CLAT-CPEs couldn't work like mobile CLATs, i.e. with NAT44 in CLAT node. 
It seems you have in mind something I couldn't get from the draft or from given explanations.

Regards,
RD

---

From: jouni korhonen <[email-masked]>
Date: Tue, 29 May 2012 22:13:29 +0300

Hi,

One comment below.

> prefix model" for wireline service that utilize DHCPv6-PD as a

For the latter I do not think the text needs to explicitly state
that the dedicated prefix model is for wireline service. Just saying
it applies for any service that utilizes DHCPv6-PD should suffice.

- Jouni