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

From: [email-masked]
Date: Mon, 16 Apr 2012 23:55:42 -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-02.txt
	Pages           : 15
	Date            : 2012-04-16

   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 mobile and wireline IPv6-only edge networks without
   encapsulation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-02.txt

---

From: Masanobu Kawashima <[email-masked]>
Date: Tue, 17 Apr 2012 16:00:07 +0900

Folks,

We have published draft-ietf-v6ops-464xlat-02.

Changes are:

- Changed document category from Informational to BCP
  - A normative language(RFC2119) has reinserted.
  - We did not see any strong opposition on this list except Remi.
    As Cameron and Lorenzo said, we should not treat as a use case
    for BIH. Remi's some concerns were fixed by this version as below.
    If you have any strong opposition, please indicate it.

- Section 7.1. IPv6 Address Format
  - Replaced all text with this one sentence "IPv6 address format
    in 464XLAT is defined in Section 2.2 of [RFC6052]"

- Section 7.2. IPv4/IPv6 address translation chart
  - Removed all references to /96
  - Added case of "CLAT with NAT44"

- Section 7.4. DNS Proxy Implementation
  - Added a reference to RFC5625

- Section 7.5. IPv6 Prefix Handling
  - Removed all references to /96
  - Added a reference to RFC3633

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, 17 Apr 2012 18:25:12 +0200

Hi, Masanobu,

Thanks for this new version.
More comments in line.

>  - We did not see any strong opposition on this list except Remi.

Let it be clear that I continuously supported quick publication of an informational RFC describing what has been tested.

OTOH, I objected to any hasty publication a normative BCP, and continue to do so because:
- there are unclear points and significant drawbacks in the specification (see (1) below)
- relationship with BIH (standard-track RFC6535) hasn't been even looked at (although BIH already supports AFAIK the 4645XLAT scenario plus some others).

> All comments are welcome.

(1)
Section 7.5 cites two IPv6 prefix-handling variants

- The first one explicitly requires two IPv6 prefixes per CLAT node, a quite expensive constraint. 

- The second one is supposed to use only one prefix, but:
 . Section 7.2 says that the CLAT IPv6 address, which is based on a single IPv4 address due to an NAT44 in the CLAT node, is defined in Section 2.2 of RFC6052.
 . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to the organization deploying the address translators." This cannot be the CLAT-node delegated prefix.

In my understanding, this second option cannot  work.
If I missed something, thank you for explaining.

(2)
Coming back to the relationship with BIH:
- We now know there is open-source running code for BIH.
- With BIH, a single IPv6 prefix per customer node is sufficient in customer nodes.
- IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with servers that, because they are also in customer sites of IPv6-only networks, can have AAAA records but no A records in the DNS.

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 17 Apr 2012 10:30:50 -0700

Remi,

> - The first one explicitly requires two IPv6 prefixes per CLAT node, a quite expensive constraint.

What is expensive?  I think most network operators will say IPv6 /64
subnets have no money value, and /64 subnets should be used where ever
it makes operational sense without constraint.

>  . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to the organization deploying the address translators."…

Why can this not be the CLAT node prefix?  NSP of the home network.

> - We now know there is open-source running code for BIH.

Same as 464XLAT draft

> - With BIH, a single IPv6 prefix per customer node is sufficient in customer nodes.

Same as defined is this 464XLAT draft

> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with servers that, because they are also in customer sites of IPv6-only networks, can have AAAA records but no A records in the DNS.

Brian, Lorenzo, Gert, and myself, and the market (there is no
meaningful market for IPv6-only services on the internet) say this is
not a value add.

CB

---

From: GangChen <[email-masked]>
Date: Wed, 18 Apr 2012 10:38:48 +0800

Hello Cameron,

> meaningful market for IPv6-only services on the internet) say this is

IMHO, the added value is similar with the benefits of DNS Proxy, i.e.
"to make the transaction native IPv6 from the CLAT and avoid stateful
translation on the PLAT." For sure, double translation to a dual-stack
server should be supported, if severs comply with market/operational
demands.

BRs

Gang

2012/4/18, Cameron Byrne <[email-masked]>:
>> Let it be clear that I continuously supported quick publication of an
>> informational RFC describing what has been tested.
>>
>> - relationship with BIH (standard-track RFC6535) hasn't been even looked
>> at (although BIH already supports AFAIK the 4645XLAT scenario plus some
>> others).
>>
>>
>>  . Section 7.2 says that the CLAT IPv6 address, which is based on a single
>> IPv4 address due to an NAT44 in the CLAT node, is defined in Section 2.2
>> of RFC6052.
>>  . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall be
>> either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to
>> the organization deploying the address translators." This cannot be the
>> CLAT-node delegated prefix.
>>
>
>> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with
>> servers that, because they are also in customer sites of IPv6-only
>> networks, can have AAAA records but no A records in the DNS.
>>
>
>>>> 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.
>>>>

---

From: Rémi Després <[email-masked]>
Date: Wed, 18 Apr 2012 14:26:43 +0200

Cameron,

2012-04-17  19:30, Cameron Byrne:
...
> it makes operational sense without constraint.

OK, expensive may not be the best qualifier.

OTOH, the need to delegate TWO IPv6 prefixes per customer, while there exist solutions that work with the ordinary one-prefix-per-customer practice, should by no means be called "Best Common Practice".

I remain firm on that.

> Why can this not be the CLAT node prefix?  NSP of the home network.

AFAIK, a single operator supports many CLATs  
They cannot be reached at the NSP prefix which, by RFC6052, is "unique to the organization deploying the address translators" (i.e the operator).

>> - We now know there is open-source running code for BIH.

Right => not a decision criterion.

> Same as defined is this 464XLAT draft

BIH can readily be used on any ISPv6 network having a NAT64 accessible at its well known prefix 64:ff9b::/96.
This isn't the case with the proposed 464XLAT design (see above).

> meaningful market for IPv6-only services on the internet) say this is

When discussing whether a new market exists, those who explain where they see it are in general more relevant than those who,  having not seen it yet, negate that it can exist.

In any case, advantages of BIH for the 464XLAT scenario go beyond BIH applicability to IPv4-only hosts reaching servers attached to IPv6-only networks.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Wed, 18 Apr 2012 22:14:37 +0900

Remi,

try to understand the question, as a learner.
2012/4/18 Rémi Després <[email-masked]>

> OTOH, the need to delegate TWO IPv6 prefixes per customer, while there
> exist solutions that work with the ordinary one-prefix-per-customer
> practice, should by no means be called "Best Common Practice".
>
> I remain firm on that.
>
> >>  . Section 7.2 says that the CLAT IPv6 address, which is based on a
> single IPv4 address due to an NAT44 in the CLAT node, is defined in Section
> 2.2 of RFC6052.
> >>  . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall
> be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to
> They cannot be reached at the NSP prefix which, by RFC6052, is "unique to
> the organization deploying the address translators" (i.e the operator).
>

i understand it depends how we understand the word "organization" in the
RFC6052 context. it is not necessarily the "operator" (of the
infrastructure or the autonomous system). exactly speaking, it is the
aggregator. in the 464xlat sec 7.5 variant case 1, the NSP is the delegated
prefix for, e.g., the home network; in the case 2, as the CLAT has not a
dedicated IPv6 prefix, the aggregator is the higher level entity (operator
or suboperator). in either case, single operator supporting many CLATs,
AFAIK, is not a problem according to the 464xlat text. the "unique" in the
context of RFC6052 is not a restriction, i think.

if my understanding is not correct, please don't hesitate to point out.
thanks!

- maoke

> When discussing whether a new market exists, those who explain where they
> see it are in general more relevant than those who,  having not seen it
> yet, negate that it can exist.
>
> In any case, advantages of BIH for the 464XLAT scenario go beyond BIH
> applicability to IPv4-only hosts reaching servers attached to IPv6-only
> networks.
>
> Regards,
> RD
>
>
>
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 18 Apr 2012 17:23:17 +0200

Maoke,

Le 2012-04-18 à 15:14, Maoke a écrit :

> i understand it depends how we understand the word "organization" in the RFC6052 context. it is not necessarily the "operator" (of the infrastructure or the autonomous system). exactly speaking, it is the aggregator.

> in the 464xlat sec 7.5 variant case 1, the NSP is the delegated prefix for, e.g., the home network;

This point of the discussion is only about case 2 (Case 1 has two IPv6 prefixes per customer, something that AFAIK is claimed to be avoided in case 2)

> in the case 2, as the CLAT has not a dedicated IPv6 prefix,

Not understood.
(It could be taken as meaning that CLAT nodes might have no IPv6 delegated prefixes.)

> the aggregator is the higher level entity (operator or suboperator). in either case, single operator supporting many CLATs, AFAIK, is not a problem according to the 464xlat text. the "unique" in the context of RFC6052 is not a restriction, i think.
>  
> if my understanding is not correct, please don't hesitate to point out. thanks!

RFC6052 specifies addresses that start with a common prefix (WKP or NSP) followed by IPv4 addresses.
I don't see how this could be used to address customer nodes whose embedded addresses are RFC1918 addresses.

Seeing a workable addressing plan for case 2 is for me a prerequisite to eliminate this doubt.

RD

---

From: Maoke <[email-masked]>
Date: Thu, 19 Apr 2012 02:15:38 +0000

Remi,

> aggregator.
> This point of the discussion is only about case 2 (Case 1 has two IPv6
> prefixes per customer, something that AFAIK is claimed to be avoided in
> case 2)
>

i don't so understand what do you refer to with the "TWO ipv6 prefixes PER
customer". do you mean the delegated prefix AND the one /64 for the purpose
of 464xlat? if the delegated prefix is larger than /64, i think the
464xlat-use prefix could be selected from this delegated prefix as a
more-specific (a /64), dedicated for 464xlat-use only. if the delegated
prefix is another /64, it is the case you mean 2 prefixes, right?

for the case 2, to my understanding, it is not "claimed to be avoided" but
another case of reality, where only the delegated prefix (one /64) is
assigned to the CLAT so that a dedicated /64 for 464xlat funtionality is
not allowed. in this case, CLAT does NAT44 so that only one IPv4-embedded
address is used for the purpose of 464xlat. it also does work.

do i miss anything?

> the aggregator is the higher level entity (operator or suboperator). in
> either case, single operator supporting many CLATs, AFAIK, is not a problem
> according to the 464xlat text. the "unique" in the context of RFC6052 is
> not a restriction, i think.
>
> I don't see how this could be used to address customer nodes whose
> embedded addresses are RFC1918 addresses.
>

i understand it is ok because 464xlat's PLAT performs stateful translation
between the IPv6 address (with RFC1918 IPv4 embedded) and a global IPv4
address in the pool that held by PLAT. (btw, i don't think WKP is used in
464xlat for the CLAT and CLAT-served hosts. RFC6052 also has the
restriction that RFC1918 addresses MUST NOT be used with WKP). is this
understanding correct? i think the case1/2 is convining enough as a
workabale addressing plan.

- maoke

---

From: Masanobu Kawashima <[email-masked]>
Date: Thu, 19 Apr 2012 16:25:39 +0900

Hi Maoke,

Thank you for explaining it so clearly.

>prefix is another /64, it is the case you mean 2 prefixes, right?

Exactly.

>address is used for the purpose of 464xlat. it also does work.

Exactly.

>address in the pool that held by PLAT.

You're right.

>(btw, i don't think WKP is used in 464xlat for the CLAT and CLAT-served
>hosts. RFC6052 also has the restriction that RFC1918 addresses MUST NOT
>be used with WKP). is this understanding correct? i think the case1/2 is
>convining enough as a workabale addressing plan.

I also think that non-global IPv4 addresses must not be used with WKP.

Regards,
Masanobu

>Remi,
>
>2012/4/18 Remi Despres <[email-masked]>
>
>> Maoke,
>>
>>
>> Le 2012-04-18 15:14, Maoke a rit :
>>
>> Remi,
>>
>> 2012/4/18 Remi Despres <[email-masked]>
>>
>>> Cameron,
>>>

---

From: Rémi Després <[email-masked]>
Date: Thu, 19 Apr 2012 10:41:31 +0200

Masanobu,

Please see comments in line.

>> prefix is another /64, it is the case you mean 2 prefixes, right?

The text in section 7.5 about case 1 is: 
"the CLAT will have a dedicated /64 via DHCPv6 prefix delegation [RFC3633] or other means to source and receive IPv6 packets associated with the [RFC6145] stateless translation of IPv4 packets to the local clients.  If the CLAT choose one /64 prefix for translation from delegated prefix, then it SHOULD NOT be used for anything else."

- In my understanding, this implies a /64 for 464XLAT, and another prefix for native IPv6.

- In a recent email, Cameron's answer about case 1 which, as I had said  "explicitly requires two IPv6 prefixes per CLAT node, a quite expensive constraint" was "What is expensive?  I think most network operators will say IPv6 /64 subnets have no money value". This was AFAIK an implicit acknowledgement that TWO prefixes were needed. (Sorry if I misinterpreted.)

>> address is used for the purpose of 464xlat. it also does work.

First, please note that the approach of draft-02 for case 2, being new, isn't one of those that were tested.
How it can work remains for me an open question.

In order to understand what you mean, I just ask for a simple example addressing plan, i.e., to be more precise:
(a) The operator NAT64 prefix
(b) The delegated /64 of an example CLAT-node
(c) The source address this CLAT uses when the IPv6 destination starts with the NAT64 prefix.

Without this, I am lost.

>> be used with WKP). is this understanding correct?

See (**) below

>> i think the case1/2 is

Let's see the example addressing plan you can provide.

> I also think that non-global IPv4 addresses must not be used with WKP.

(**)
Well, not a matter of thinking: its written in RFC6052!
 
=> Source addresses from CLATs, which are RFC6052 based in your proposal, are indeed concerned with this rule.
But let's also no forget that destination addresses from CLATs contain GLOBAL IPv4 addresses => they aren't concerned.

My doubt that case 2 can work, as currently specified, is independent from what RFC6052 says on NSPs and RFC1918 addresses.
Only an example addressing plan, with its (a) (b) (c) above, can AFAIK clarify the issue.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Thu, 19 Apr 2012 11:32:44 +0000

Remi,

only what i have understood (sorry but i answer your mail to Masanobu but
let me also verify my understanding).

2012/4/19 Rémi Després <[email-masked]>

> "the CLAT will have a dedicated /64 via DHCPv6 prefix delegation [RFC3633]
> or other means to source and receive IPv6 packets associated with the
> [RFC6145] stateless translation of IPv4 packets to the local clients.  If
> the CLAT choose one /64 prefix for translation from delegated prefix, then
> it SHOULD NOT be used for anything else."
>
> - In a recent email, Cameron's answer about case 1 which, as I had said
>  "explicitly requires two IPv6 prefixes per CLAT node, a quite expensive
> constraint" was "What is expensive?  I think most network operators will
> say IPv6 /64 subnets have no money value". This was AFAIK an implicit
> acknowledgement that TWO prefixes were needed. (Sorry if I misinterpreted.)
>

i think this part we are almost on the same floor.

"the CLAT will have a dedicated /64 via DHCPv6 prefix delegation [RFC3633]
or other means to source and receive IPv6 packets associated with the
[RFC6145] stateless translation of IPv4 packets to the local clients." => a
dedicated /64 only for the 464xlat-use; if there is another /64 for native
IPv6-use only, then there are two prefixes. e.g., 2001:db8:1234:5678::/64
dedicated for a CLAT'x 464xlat use while another, 2001:db8:1234:5679::/64
for other purposes.

"If the CLAT choose one /64 prefix for translation from delegated prefix,
then it SHOULD NOT be used for anything else." => "one /64" chosen "from
delegated prefix" (surely the delegated prefix should be larger than /64
otherwise one cannot "choose" a /64 from it), then it (=> the /64 for
464xlat-use) should not be used for anything else (=> but only the
464xlat-use). in this case, you may call it *TWO* prefices or *ONE* prefix
because they are able to aggregate, the delegated prefix. e.g.,
2001:db8:1234:5670:/60 as the delegated prefix while
2001:db8:1234:5678::/64 is dedicated to 464xlat.

i don't find any problem there and Cameron's answer is also qualified. if
you certainly refer to these *TWO* prefices, then i think the question has
been cleared.

> In order to understand what you mean, I just ask for a simple example
> addressing plan, i.e., to be more precise:

i think there is not so much "being new", except the /96 being removed.
taking the example from the authors' presentation in IETF83 (but let me
replace the /96 with RFC6052 format)
(a) 2001:db8:1234:0::/64.
(b) 2001:db8:aaaa:0::/64.
(c) as case 2, 2001:db8:aaaa:0:00c0:a801:0200::/128 (192.168.1.2 =
0xc0a80102) only is used for this CLAT 464xlat funtionality (private IPv4
addresses inside in the subnet served by CLAT is translated to 192.168.1.2
through NAT44 integrated in the CLAT.), while destination (when having
access to 198.51.100.1 = 0xc6336401) will be
2001:db8:1234:0:00c6:3364:0100::.

what is the concern? do you mean (a) and (b) are not *a* "unique NSP" (for
the organization, in the context of RFC6052)? if this is the concern, i
think the problem is you think the "organization" in the RFC6052 = "the
operator", but here it is not the case. AFAIK, RFC6052 never states that. i
understand here the CLAT holder and the PLAT owner are of the
"organizations".

>
> Without this, I am lost.
>
>
> >>> RFC6052 specifies addresses that start with a common prefix (WKP or
> NSP)
> >>> followed by IPv4 addresses.
> But let's also no forget that destination addresses from CLATs contain
> GLOBAL IPv4 addresses => they aren't concerned.
>

they have been concerned, to my understanding. well, maybe
source/destination is not accurate because the source CLAT will be the
destination for the reply. anyway, we know what it is meaning. let me
change the term as "remote peer" rather than "destination".

for the remote peer address belonging to the outside IPv4 world, it should
be attached with the PLAT 464xlat prefix, and section 7.5 has specified how
CLAT know this information. on the other hand, because here it is the
GLOBAL IPv4 address and therefore the restriction of not using WKP is not
needed for this address (sure it is not necessary to RECOMMEND that we use
WKP for the global IPv4 addresses of the remote peers, while neither i, for
the time being, have found any reason of FORBID using it.)

for both views on CLAT and PLAT, i think the current statement in v02 is
enough. sure i do support the wording and phrasing should/could be refined
further, with examples where it is needed.

>
>
> My doubt that case 2 can work, as currently specified, is independent from
> what RFC6052 says on NSPs and RFC1918 addresses.

hope i have clarified it. if there is anything i made wrong, corrections
and/or further questions are welcome.

- maoke

> >>>>>> - The first one explicitly requires two IPv6 prefixes per CLAT
> node, a
> >>>> quite expensive constraint.
> >>>>>>
> >>>>>
> >>> (It could be taken as meaning that CLAT nodes might have no IPv6
> delegated
> >>> prefixes.)
> >>>
> >>>
> >>> RFC6052 specifies addresses that start with a common prefix (WKP or
> NSP)
> >>> followed by IPv4 addresses.
> >>> Seeing a workable addressing plan for case 2 is for me a prerequisite
> to
> >>> eliminate this doubt.
> >>>
> >>
> >>> RD
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> - maoke
> >>>
> >>>
> >>>>
> >>>> BIH can readily be used on any ISPv6 network having a NAT64
> accessible at
> >>>> its well known prefix 64:ff9b::/96.

---

From: Rémi Després <[email-masked]>
Date: Thu, 19 Apr 2012 15:28:51 +0200

2012-04-19  13:32, Maoke:

...
>  if you certainly refer to these *TWO* prefices, then i think the question has been cleared.

If we agree that sec.7.5 case 1 requires two delegated prefixes per customer, yes, this question cleared. 

> i think there is not so much "being new", except the /96 being removed. taking the example from the authors' presentation in IETF83 (but let me replace the /96 with RFC6052 format)
> (c) as case 2, 2001:db8:aaaa:0:00c0:a801:0200::/128 (192.168.1.2 = 0xc0a80102) only is used for this CLAT 464xlat funtionality (private IPv4 addresses inside in the subnet served by CLAT is translated to 192.168.1.2 through NAT44 integrated in the CLAT.), while destination (when having access to 198.51.100.1 = 0xc6336401) will be 2001:db8:1234:0:00c6:3364:0100::. 

Thanks for providing this example.
As expected, it does clarify what you mean.
With this understanding, I will try to make constructive suggestions on how to progress.

Thanks,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 19 Apr 2012 16:37:32 +0200

Masanobu, Masataka, Cameron,

After clarifications exchanged on the ML, both about 464XLAT and about an available BIH implementation, here is a proposal which, if accepted, would normally lead me to support a 4X4XLAT BCP:

(a) Only describe the solution where a single IPv6 prefix per CLAT node is enough (i.e. case 2 of Section 7.5, with NAT44 in the node)

(b) Add support of CLAT prefixes shorter than /64

(c) Concerning the IPv6 address used in a CLAT node to reach the CLAT, mention two approaches:
- c1 (roughly that of the current case 2): use a RFC6052-based 464XLAT specific address, based on a locally defined NSP (equal to or starting with the CLAT-node IPv6 prefix), and embedding the RFC1918 address chosen as NAT44 external address. For this approach, make clear that, on the LAN side, two IPv6 addresses need to be excluded instead of one in absence of 464XLAT support.
- c2 (no 464XLAT-specific IPv6 address needed): All CLAT-node incoming packets coming from the NAT64 (i.e. whose source addresses start with the NAT64 prefix) are addressed to the NAT44, and all CLAT outgoing packets have the native IPv6 address of the WAN interface.

(d) Explicitly permit the NAT64 prefix to be the NAT64 WKP.

(e) Mention that a superset of the CLAT behavior is available in RFC6535 for nodes supporting the network-layer BIH with a NAT44, the difference being that, in addition, RFC6535 supports connectivity of IPv4-only hosts, or applications, with servers whose only public addresses are IPv6. 

(f) For clarification, replace "PLAT" by "NAT64" (AFAIK identical, and already defined).

Questions and comments are welcome.

The above, made after a serious technical debate for which I thank all those who participated, will hopefully be taken for what it is: a constructive contribution to improve an interesting proposal.

Kind regards,
RD

---

From: Maoke <[email-masked]>
Date: Fri, 20 Apr 2012 00:47:44 +0900

hi Remi and the authors,

as an observer, 1) i don't think (f) is needed (NAT64 is the function while
PLAT is a building block of this specific architecture); 2) i don't think
(e) is necessary as 464xlat and BIH are in different scopes, with different
environment of deployment. i don't think one could be said as a superset of
another. only personal point of view.

thanks,
maoke

> After clarifications exchanged on the ML, both about 464XLAT and about an
> available BIH implementation, here is a proposal which, if accepted, would
> normally lead me to support a 4X4XLAT BCP:
>
> (a) Only describe the solution where a single IPv6 prefix per CLAT node is
> enough (i.e. case 2 of Section 7.5, with NAT44 in the node)
>
> - c1 (roughly that of the current case 2): use a RFC6052-based 464XLAT
> specific address, based on a locally defined NSP (equal to or starting with
> the CLAT-node IPv6 prefix), and embedding the RFC1918 address chosen as
> NAT44 external address. For this approach, make clear that, on the LAN
> side, two IPv6 addresses need to be excluded instead of one in absence of
> 464XLAT support.
> - c2 (no 464XLAT-specific IPv6 address needed): All CLAT-node incoming
> packets coming from the NAT64 (i.e. whose source addresses start with the
> NAT64 prefix) are addressed to the NAT44, and all CLAT outgoing packets
> have the native IPv6 address of the WAN interface.
>
> (e) Mention that a superset of the CLAT behavior is available in RFC6535
> for nodes supporting the network-layer BIH with a NAT44, the difference
> being that, in addition, RFC6535 supports connectivity of IPv4-only hosts,
> or applications, with servers whose only public addresses are IPv6.
>
> The above, made after a serious technical debate for which I thank all
> those who participated, will hopefully be taken for what it is: a
> constructive contribution to improve an interesting proposal.
>
> Kind regards,
> RD
>
>
>
>

---

From: Dan Drown <[email-masked]>
Date: Thu, 19 Apr 2012 12:10:44 -0500

Quoting Rémi Després <[email-masked]>:
> (a) Only describe the solution where a single IPv6 prefix per CLAT  
> node is enough (i.e. case 2 of Section 7.5, with NAT44 in the node)

Hello, I believe I can help with this question by using the Android  
clat implementation as an example.

I took these addresses from my phone connected via T-Mobile's network

PLAT prefix (detected through DNS64) - fd00:976a:c305:692e::/96
Phone IPv6 subnet  - 2607:fb90:800:68c::/64
Phone IPv6 address - 2607:fb90:800:68c::eae6:901
CLAT IPv6 address  - 2607:fb90:800:68c:abcd:0:aff:ff01
CLAT IPv4 address  - 10.255.255.1

The CLAT v4 and v6 addresses are a simple 1 to 1 relation, and v4  
tethering clients are NAT44'd to the CLAT v4 address.  v6 tethering  
would require the phone to proxy ND respond for the CLAT v6 address.   
Since proxy ND requires joining multicast groups based on the address,  
it's much easier to proxy ND a /128 than a /96.

---

From: Rémi Després <[email-masked]>
Date: Thu, 19 Apr 2012 22:58:18 +0200

Dan, 
Thank you for these data.

Le 2012-04-19 à 19:10, Dan Drown a écrit :

> Hello, I believe I can help with this question by using the Android clat implementation as an example.
> 
> The CLAT v4 and v6 addresses are a simple 1 to 1 relation, and v4 tethering clients are NAT44'd to the CLAT v4 address.  

> v6 tethering would require the phone to proxy ND respond for the CLAT v6 address.

Apparently, then, your Android host only offers IPv4 to tethered hosts. (Since it is attached to an IPv6-only network, this restriction should obviously be provisional).

>  Since proxy ND requires joining multicast groups based on the address, it's much easier to proxy ND a /128 than a /96.

In my understanding, that is two /128s that should be proxied: 2607:fb90:800:68c::eae6:901 AND 2607:fb90:800:68c:abcd:0:aff:ff01). 

Note that this need for TWO proxied addresses, which goes beyond what is done in ordinary IPv6 CPEs, would be avoided with my proposal c2 of http://www.ietf.org/mail-archive/web/v6ops/current/msg12660.html:
- CLAT outgoing packets would have SRC = 2607:fb90:800:68c::eae6:901, and DST starting with fd00:976a:c305:692e::/96
- CLAT incoming packets (to be submitted to the NAT44) would be recognized by their SRCs starting with fd00:976a:c305:692e::/96 
- No CLAT IPv4 address would appear anywhere on the wire (but 10.255.255.1 can be used as NAT external address if needed by the NAT44 code) 

Regards,
RD

---

From: Dan Drown <[email-masked]>
Date: Thu, 19 Apr 2012 18:18:13 -0500

Quoting Rémi Després <[email-masked]>:
> Apparently, then, your Android host only offers IPv4 to tethered  
> hosts. (Since it is attached to an IPv6-only network, this  
> restriction should obviously be provisional).

The handset can source IPv4 traffic using the CLAT IPv4 address as  
well as NAT44 the IPv4 tethering traffic.

> In my understanding, that is two /128s that should be proxied:  
> 2607:fb90:800:68c::eae6:901 AND 2607:fb90:800:68c:abcd:0:aff:ff01).

Thankfully, one can re-use the interface ip  
(2607:fb90:800:68c::eae6:901 in this case) on both the outside (cell  
network) and inside (wifi tethering) interfaces.  So it's just the  
CLAT /128 that needs proxy ND.

> Note that this need for TWO proxied addresses, which goes beyond  
> what is done in ordinary IPv6 CPEs, would be avoided with my  
> proposal c2 of  
> http://www.ietf.org/mail-archive/web/v6ops/current/msg12660.html:
> - CLAT outgoing packets would have SRC =  
> 2607:fb90:800:68c::eae6:901, and DST starting with  
> fd00:976a:c305:692e::/96
> - CLAT incoming packets (to be submitted to the NAT44) would be  
> recognized by their SRCs starting with fd00:976a:c305:692e::/96
> - No CLAT IPv4 address would appear anywhere on the wire (but  
> 10.255.255.1 can be used as NAT external address if needed by the  
> NAT44 code)

I am constrained by my implementation choices.  Since I used a tun  
interface and userland code, I need a dedicated IPv6 address for CLAT  
(traffic is sent to the tun interface by ipv6 forwarding).  An  
implementation inside the kernel would be able to do what you ask, but  
it would come at a higher maintenance cost.  Perhaps my concerns are  
outside the relm of what a specification should be concerned about,  
though.

---

From: Maoke <[email-masked]>
Date: Fri, 20 Apr 2012 01:34:44 +0000

sorry i missed to respond this point.

> customer, yes, this question cleared.

"case 1 requires" would be a little misleading, giving an impression that
one chooses case 1 then he/she must have two prefices otherwise he/she
fails the deployment. it is not incorrect but the logic is inverse to the
practice of deployment.

the practice is: if i have several prefices for a CLAT or a prefices with
higher level of aggregation, then i may consider to deploy case 1; if i
have only one /64, i deploy case 2 instead. one prefix or two prefices are
of condition of deployment rather than the "requirement". 464xlat doesn't
preset either case 1 or 2 as prerequisite of any deployment.

as a whole, 464xlat doesn't *require* two delegated prefices per customer,
but it suggests to decide (not *choose*) between case 1 and 2 according to
the condition in reality.

hope it clarifies.

- maoke

---

From: GangChen <[email-masked]>
Date: Fri, 20 Apr 2012 13:41:08 +0800

> CLAT /128 that needs proxy ND.

Just wondering to know how could re-use the ip address, which already
used on outside?
http://tools.ietf.org/html/draft-ietf-dhc-pd-exclude give me a hint it
should be excluded in Lan side

>> 10.255.255.1 can be used as NAT external address if needed by the

+1

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Fri, 20 Apr 2012 11:05:19 +0200

Le 2012-04-20 à 01:18, Dan Drown a écrit :

> The handset can source IPv4 traffic using the CLAT IPv4 address as well as NAT44 the IPv4 tethering traffic.
> 
> Thankfully, one can re-use the interface ip (2607:fb90:800:68c::eae6:901 in this case) on both the outside (cell network) and inside (wifi tethering) interfaces.  So it's just the CLAT /128 that needs proxy ND.

Two interfaces having the same IPv6 address (2607:fb90:800:68c::eae6:901 in this case) would break the RFC4291 model which has:
"An IPv6 unicast address refers to a single interface."

> I am constrained by my implementation choices.  Since I used a tun interface and userland code, I need a dedicated IPv6 address for CLAT (traffic is sent to the tun interface by ipv6 forwarding).  

Note that, by using TAP instead of TUN, your implementation could remain in user space while operating at the link layer (http://en.wikipedia.org/wiki/TUN/TAP).
Then, with my c2 proposal, proxy ND for 2607:fb90:800:68c::eae6:901 can be enough (607:fb90:800:68c:abcd:0:aff:ff01 isn't used), and RFC4291 is complied with.
Thought? 
RD

> An implementation inside the kernel would be able to do what you ask, but it would come at a higher maintenance cost.  Perhaps my concerns are outside the relm of what a specification should be concerned about, though.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Apr 2012 19:31:51 +0900

On Fri, Apr 20, 2012 at 08:18, Dan Drown <[email-masked]> wrote:

>> 10.255.255.1 can be used as NAT external address if needed by the NAT44
>> code)
>>
>
> (traffic is sent to the tun interface by ipv6 forwarding).

Why does the CLAT interface need an IPv6 address in order to forward
packets to it? Is it because you specify 2607:fb90:800:68c:abcd:0:aff:ff01
as the next hop? If so, can't you specify something like "dev clat" instead
of "via 2607:fb90:800:68c:abcd:0:aff:ff01" in the route?

---

From: Dan Drown <[email-masked]>
Date: Fri, 20 Apr 2012 10:42:46 -0500

Quoting Rémi Després <[email-masked]>:
> Two interfaces having the same IPv6 address  
> (2607:fb90:800:68c::eae6:901 in this case) would break the RFC4291  
> model which has:

I do not see the harm in re-using a point to point interface's address  
(which is configured as a /128) on one ethernet interface.  The  
alternative would be to proxy ND that address, and I do not see the  
benefit.

> Note that, by using TAP instead of TUN, your implementation could  
> remain in user space while operating at the link layer  
> (http://en.wikipedia.org/wiki/TUN/TAP).
> Then, with my c2 proposal, proxy ND for 2607:fb90:800:68c::eae6:901  
> can be enough (2607:fb90:800:68c:abcd:0:aff:ff01 isn't used), and  
> RFC4291 is complied with.

TAP would require additional implementation work in two areas:

1. switching the android tethering system to using an ethernet  
bridging configuration

2. switching the android-clat software from dealing with IP packets to  
dealing with ethernet packets, including adding ND support

Doing this would eliminate the need to proxy ND the clat address.   
This would not fix the duplicate phone address issue, as the cell  
network interface is a point to point interface and not ethernet.

I believe that using proxy ND is an acceptable alternative to  
switching to TAP.

> of "via 2607:fb90:800:68c:abcd:0:aff:ff01" in the route?

It's not the phone's interface that needs the IP, it's the CLAT  
function that needs the IP.  All v6 traffic to and from the CLAT  
software needs a v6 address to distinguish it from the phone's native  
v6 traffic.

---

From: Rémi Després <[email-masked]>
Date: Fri, 20 Apr 2012 18:03:23 +0200

Le 2012-04-20 à 17:42, Dan Drown a écrit :

> I do not see the harm in re-using a point to point interface's address (which is configured as a /128) on one ethernet interface.  The alternative would be to proxy ND that address, and I do not see the benefit.
> 
>> Then, with my c2 proposal, proxy ND for 2607:fb90:800:68c::eae6:901 can be enough (2607:fb90:800:68c:abcd:0:aff:ff01 isn't used), and RFC4291 is complied with.
> 
> 1. switching the android tethering system to using an ethernet bridging configuration

Why?
- Can't the CLAT take packets it is concerned with from incoming Ethernet frames, and return other frames to the kernel, thus changing nothing for native IPv6?
- The IPv4 router, because it is isolated from the WAN interface by the NAT44, isn't concerned with the WAN side of the CLAT.
> 
> 2. switching the android-clat software from dealing with IP packets to dealing with ethernet packets, including adding ND support

Can't TAP be used to treat incoming traffic at L2, and TUN to treat outgoing traffic at L3?

RD

> Doing this would eliminate the need to proxy ND the clat address.  This would not fix the duplicate phone address issue, as the cell network interface is a point to point interface and not ethernet.
> 
> I believe that using proxy ND is an acceptable alternative to switching to TAP.
> 
> It's not the phone's interface that needs the IP, it's the CLAT function that needs the IP.  All v6 traffic to and from the CLAT software needs a v6 address to distinguish it from the phone's native v6 traffic.

---

From: Dan Drown <[email-masked]>
Date: Fri, 20 Apr 2012 12:27:15 -0500

Quoting RÃ©mi DesprÃ©s <[email-masked]>:
> Why?
> - Can't the CLAT take packets it is concerned with from incoming  
> Ethernet frames, and return other frames to the kernel, thus  
> changing nothing for native IPv6?

Incoming packets in my case (from the cell network) are not  
encapsulated in ethernet.  The TAP driver in Linux is named somewhat  
confusingly, because it has nothing to do with "ethernet taps".  The  
TAP driver provides a way to emulate an ethernet interface in  
user-land software.

I believe what you are thinking of something more along the lines of  
iptable's NFQUEUE target, which can take a packet and pass it to  
userspace before processing it locally.  That could be used to share  
the same IPv6 address between the CLAT function and the host.  It  
would be tricky to seperate native v6 traffic from the phone to the  
PLAT prefix (an application that can use DNS64) and CLAT traffic, but  
mostly possible by reserving port ranges.

But I still don't see the value that this added complexity brings.   
Why all this work to avoid proxy ND?

---

From: Rémi Després <[email-masked]>
Date: Fri, 20 Apr 2012 22:08:08 +0200

Le 2012-04-20 à 19:27, Dan Drown a écrit :

> Incoming packets in my case (from the cell network) are not encapsulated in ethernet.  The TAP driver in Linux is named somewhat confusingly, because it has nothing to do with "ethernet taps".  The TAP driver provides a way to emulate an ethernet interface in user-land software.
> 
> I believe what you are thinking of something more along the lines of iptable's NFQUEUE target, which can take a packet and pass it to userspace before processing it locally.  That could be used to share the same IPv6 address between the CLAT function and the host.

OK, You must be right. (I am not specialist of Linux myself.)

>  It would be tricky to seperate native v6 traffic from the phone to the PLAT prefix (an application that can use DNS64) and CLAT traffic, but mostly possible by reserving port ranges.

Not need to mingle with port ranges: CLAT traffic is easily recognizable by remote IPV6 addresses starting with the NAT64 prefix.

RD

> 
> But I still don't see the value that this added complexity brings.  Why all this work to avoid proxy ND?

---

From: Dan Drown <[email-masked]>
Date: Fri, 20 Apr 2012 17:50:36 -0500

Quoting Rémi Després <[email-masked]>:
> Not need to mingle with port ranges: CLAT traffic is easily  
> recognizable by remote IPV6 addresses starting with the NAT64 prefix.

This would be correct if it weren't for DNS64.  Traffic from regular  
applications can send traffic directly to the PLAT prefix from the  
phone's IPv6 address (for example: typing "http://ipv4.google.com" in  
a web browser).  This traffic does not go through CLAT, and should not  
conflict with CLAT traffic.

On a side note, I apologize for my mail client mangling your name.  It  
was on the default character set, which did a poor job with unicode.   
I believe it to be fixed now.

---

From: Rémi Després <[email-masked]>
Date: Sat, 21 Apr 2012 07:45:16 +0200

Le 2012-04-21 à 00:50, Dan Drown a écrit :

> This would be correct if it weren't for DNS64.  Traffic from regular applications can send traffic directly to the PLAT prefix from the phone's IPv6 address (for example: typing "http://ipv4.google.com" in a web browser).  This traffic does not go through CLAT, and should not conflict with CLAT traffic.

Why would this be?
DNS64 needs to know the NAT64 prefix for AAAA synthesis, and must be internally configured with this prefix, but its address doesn't start with this prefix.

RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 21 Apr 2012 10:50:05 +0200

Dan,

Sorry for having answered too hastily (copied mail below).

You are right: some incoming packets in CLAT nodes may come from the NAT64 without being destined to the CLAT. (Destined to an IPv6 application having obtained a AAAA from a DNS64).
Thank you for pointing this out.

Now, avoiding ND proxy on two addresses REMAINS POSSIBLE.
- It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an ID that no host may legitimately use).
- This can be done, in compliance with RFC 5342, with a modified-EUI-64 ID based on IANA's OUI.
- Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range of www.iana.org/assignments/ethernet-numbers for this).

Experiments can start immediately and, according to RFC 5342, IANA registration needs only that:
- Sec. 2.2: it "must be documented in an Internet Draft".
- Sec. 5.1: after a "light sanity check", an expert appointed by the IESG has no objection.

Then:
- Proxying the CLAT address on the LAN interface is no longer needed.
- ISPs can, by means of this interface ID, recognize doubly-translated packets (e.g. for traffic monitoring, as mentioned in section 8 of the 464XLAT draft-02).   

Would you agree on this?  

Regards,
RD

> De : Rémi Després <[email-masked]>
> Date : 2012-04-21 07:45
> À : Dan Drown <[email-masked]>
> Cc : v6ops WG <[email-masked]>
> Objet : Rép : [v6ops] I-D Action: draft-ietf-v6ops-464xlat-02.txt
> 
>

---

From: Dan Drown <[email-masked]>
Date: Sat, 21 Apr 2012 19:20:46 -0500

Quoting Rémi Després <[email-masked]>:
> - It is sufficient that a CLAT interface ID be reserved by IETF/IANA  
> (an ID that no host may legitimately use).
> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available  
> range of www.iana.org/assignments/ethernet-numbers for this).
...
> Would you agree on this?

This sounds good to me.  Using IANA's EUI-64 ID would avoid conflicts  
with possible interface IDs on v6 tethering (as long as a unique  
EUI-64 address is assigned to clat).  Since this is just a config file  
change, I'll go ahead and use it.

Thank you,
Dan

---

From: GangChen <[email-masked]>
Date: Mon, 23 Apr 2012 14:24:57 +0800

Hello Dan Drown,

2012/4/20, Dan Drown <[email-masked]>:
> (which is configured as a /128) on one ethernet interface.

Wondering to know which interface (i.e. cell int or wifi tethering
int) should be selected if applications on the phone are going to send
packages in the case of re-using same IPv6 address

BRs

Gang

---

From: Dan Drown <[email-masked]>
Date: Mon, 23 Apr 2012 10:57:16 -0500

> packages in the case of re-using same IPv6 address

I apologize if I've misunderstood your question, but I believe you're  
wondering about (kernel) source address selection.

http://linux-hacks.blogspot.com/2008/07/default-address-selection-part-2.html  
has a good description of the process if you want more detail.  But in  
this case (two addresses with the same scope on different interfaces),  
Linux will prefer the address on the interface associated with the  
route to the destination.

---

From: GangChen <[email-masked]>
Date: Tue, 24 Apr 2012 14:01:05 +0800

Hello Dan

> route to the destination.

Thanks for providing the information. I listed below to double confirm
the process
Assuming IPv6 apps on the CLAT would talk to severs either on cell
network side or wifi tethering network side
I guess CLAT should bind apps to different interface (i.e PPP int or
eth int) according to the route to the destination.
Eg:
PPP_int: 2607:fb90:800:68c::eae6:901
eth_int: 2607:fb90:800:68c::eae6:901

In the case,
CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int)
Des: eth_int 2607:fb90:800:68c::eae6:902

Select: eth_int: 2607:fb90:800:68c::eae6:901

BRs

Gang

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Apr 2012 17:50:44 +0900

On Sat, Apr 21, 2012 at 17:50, Rémi Després <[email-masked]>wrote:

> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range of
> www.iana.org/assignments/ethernet-numbers for this).
>

What if the user manually specifies the interface ID on a tethered device?
Will DAD just fail?

---

From: Rémi Després <[email-masked]>
Date: Tue, 24 Apr 2012 11:46:52 +0200

Le 2012-04-24 à 10:50, Lorenzo Colitti a écrit :

> On Sat, Apr 21, 2012 at 17:50, Rémi Després <[email-masked]> wrote:
> What if the user manually specifies the interface ID on a tethered device? Will DAD just fail?

Good point.
A host that is manually configured (not typical but possible) might by mistake try to use the 464XLAT reserved IID.
Avoiding possible consequences of such a mis-configuration is preferable.

For this, a requirement can be added that a CLAT node should, in its ND answers on its LAN side, refuse the 464XLAT-reserved interface ID. 
The difference with the ND proxy on two legitimate host addresses, is then only that it is just a security protection, normally no applicable.
This difference is very minor, but using a well known interface ID has other advantages:
- It facilitates traffic monitoring, and maintenance.
- It also eliminates the need to explain that:
 . customers are RFC6052 operators having their own NSPs (somewhat confusing IMHO)
 . their translators work with two service-provider prefixes (not needed).

RD

---

From: Maoke <[email-masked]>
Date: Tue, 24 Apr 2012 19:53:48 +0900

Remi,

在 2012年4月24日星期二，Rémi Després 写道：

> On Sat, Apr 21, 2012 at 17:50, Rémi Després <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range
>> of www.iana.org/assignments/ethernet-numbers for this).
>>
>
> A host that is manually configured (not typical but possible) might by
> mistake try to use the 464XLAT reserved IID.
> For this, a requirement can be added that a CLAT node should, in its ND
> answers on its LAN side, refuse the 464XLAT-reserved interface ID.
> The difference with the ND proxy on two legitimate host addresses, is then
> only that it is just a security protection, normally no applicable.
i couldn't catch your point. even now two prefices are not *needed*.
- maoke

RD

---

From: Maoke <[email-masked]>
Date: Tue, 24 Apr 2012 19:56:44 +0900

Remi,

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 24 Apr 2012 14:11:24 +0200

> i couldn't catch your point. even now two prefices are not *needed*. 

If a CLAT uses the NAT64 prefix for upstream IPv4 addresses and  a CLAT-site prefix for downstream IPv4 addresses, it is my understanding that it works with two RFC6052 prefixes.

RD

---

From: Maoke <[email-masked]>
Date: Tue, 24 Apr 2012 21:24:50 +0900

j

在 2012年4月24日星期二，Rémi Després 写道：

>> The difference with the ND proxy on two legitimate host addresses, is
>> then only that it is just a security protection, normally no applicable.
> If a CLAT uses the NAT64 prefix for upstream IPv4 addresses and  a
> CLAT-site prefix for downstream IPv4 addresses, it is my understanding that
> it works with two RFC6052 prefixes.
>

so you mean a prefix for remote peer while another for local site, right?
if so, first, i think it is natural to have different prefices for peers
not belonging to the same network; second, the NAT64 prefix is common in
the deployment domain and does not belong to a CLAT. if we have n CLATs, we
need n+1 prefices rather than 2n. calling them "a CLAT needs two prefices"
is IMHO misleading. - maoke

---

From: Rémi Després <[email-masked]>
Date: Tue, 24 Apr 2012 14:34:35 +0200

Le 2012-04-24 à 14:24, Maoke a écrit :

> so you mean a prefix for remote peer while another for local site, right? if so, first, i think it is natural to have different prefices for peers not belonging to the same network;

The point is that, with a NAT44 in a CLAT node, there is no need for the CLAT to be configured with a local-site RFC6052 prefix.

> second, the NAT64 prefix is common in the deployment domain and does not belong to a CLAT.

The RFC6145 translator of the CLAT must be configured with it to translate remote peer addresses.

> if we have n CLATs, we need n+1 prefices rather than 2n. calling them "a CLAT needs two prefices" is IMHO misleading.

Unless 464XLAT authors or implementers are also interested in this particular debate, end of this subject for me. 

RD

---

From: Maoke <[email-masked]>
Date: Wed, 25 Apr 2012 00:29:48 +0900

在 2012年4月24日星期二，Rémi Després 写道：

> not belonging to the same network;
>
>
> The point is that, with a NAT44 in a CLAT node, there is no need for the
> CLAT to be configured with a local-site RFC6052 prefix.
>
> if we have n CLATs, we need n+1 prefices rather than 2n. calling them "a
> CLAT needs two prefices" is IMHO misleading.
>
>
> Unless 464XLAT authors or implementers are also interested in this
> particular debate, end of this subject for me.
>

 thanks for replying the points. sorry if my comment made an impression of
"debate" but i only wanted to confirm if there are really different pairs
of prefices that you mean. you confirmation is enough. end for me. - maoke

---

From: Dan Drown <[email-masked]>
Date: Tue, 24 Apr 2012 11:18:59 -0500

> Select: eth_int: 2607:fb90:800:68c::eae6:901

The only thing I would change in your explanation is: this is the  
generic process that happens to all Linux machines with multiple ipv6  
interfaces, it is not something specific to or changed in CLAT or  
464XLAT.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 27 Apr 2012 03:35:42 -0700

Hi All,

Is there any suggested text from the conclusion of this threat that
should be brought into the 03 update of the draft?

CB

On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown <[email-masked]> wrote:
> The only thing I would change in your explanation is: this is the generic
> process that happens to all Linux machines with multiple ipv6 interfaces, it
> is not something specific to or changed in CLAT or 464XLAT.
>

---

From: Rémi Després <[email-masked]>
Date: Fri, 27 Apr 2012 14:32:36 +0200

Dan, Gang, Cameron,

Could this issue be clarified?

In my understanding:
- With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications communicate via this router.
- In this router:
 . WAN-side servers, because they have public IPv4 addresses, are reached via the NAT44, and in case of IPv6-only network having a NAT64 via the CLAT (but not via the in-node IPv6 router)
 . LAN-side servers, because they have RFC1918 addresses, are reached in IPv4 via the in-node router. They are not concerned with IPv6.
With this understanding, no text needs to be added in the specification (or only to clarify the above).

Anything missed?

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 27 Apr 2012 08:39:26 -0700

On Apr 27, 2012 5:32 AM, "Rémi Després" <[email-masked]> wrote:
>  . WAN-side servers, because they have public IPv4 addresses, are reached
via the NAT44, and in case of IPv6-only network having a NAT64 via the CLAT
(but not via the in-node IPv6 router)
>  . LAN-side servers, because they have RFC1918 addresses, are reached in
IPv4 via the in-node router. They are not concerned with IPv6.
> With this understanding, no text needs to be added in the specification
(or only to clarify the above).

I think your understanding is the same as mine, if you are saying the 02
revision does not need modification.

For LAN to LAN communication, the CLAT does not modify packets.

For LAN to WAN, CLAT does not modify ipv6 packets either to the public ipv6
server or to ipv4 servers that are reached via PLAT + DNS64.  For LAN ipv4
to WAN ipv4 across an ipv6-only access network, nat44 & rfc6145 are applied
at the clat and rfc 6146 at the PLAT.  Unless there is a larger than /64
prefix assigned to the CLAT, then the CLAT only needs to do rfc6145 and no
nat44.

This behavior is documented in the draft 02 is in the traffic treatment
scenario chart.

Cb

> >> The only thing I would change in your explanation is: this is the
generic
 On Apr 27, 2012 5:32 AM, "Rémi Després" <[email-masked]> wrote:

>  . WAN-side servers, because they have public IPv4 addresses, are reached
> via the NAT44, and in case of IPv6-only network having a NAT64 via the CLAT
> (but not via the in-node IPv6 router)
>  . LAN-side servers, because they have RFC1918 addresses, are reached in
> IPv4 via the in-node router. They are not concerned with IPv6.
> generic

---

From: Rémi Després <[email-masked]>
Date: Fri, 27 Apr 2012 18:25:18 +0200

Le 2012-04-27 à 17:39, Cameron Byrne a écrit :

> I think your understanding is the same as mine, if you are saying the 02 revision does not need modification.
> 
> For LAN to WAN, CLAT does not modify ipv6 packets either to the public ipv6 server or to ipv4 servers that are reached via PLAT + DNS64.  For LAN ipv4 to WAN ipv4 across an ipv6-only access network, nat44 & rfc6145 are applied at the clat and rfc 6146 at the PLAT. 
> 

In full sync so far.

> Unless there is a larger than /64 prefix assigned to the CLAT, then the CLAT only needs to do rfc6145 and no nat44.
> 
In case of tethering, which is the context discussed by Gang and Dan, always including a NAT44 is in my understanding much simpler than trying to dispense with it.
I see no need to document anything else in a BCP.

Now, I agree that a CLAT node WITHOUT tethering MAY dispense with a NAT44.
But it is worth noting that it MAY include a NAT44, in which case a common architecture applies to all cases.

> This behavior is documented in the draft 02 is in the traffic treatment scenario chart.
> 
If the NAT44 is the IPv4 client of the scenario chart, the chart can apply as well to tethering as to tethering-less. It becomes generic.

RD

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 27 Apr 2012 12:02:51 -0700

Rémi

On Fri, Apr 27, 2012 at 9:25 AM, Rémi Després <[email-masked]> wrote:
> at the clat and rfc 6146 at the PLAT.
>
>
> In full sync so far.
>
> In case of tethering, which is the context discussed by Gang and Dan, always
> including a NAT44 is in my understanding much simpler than trying to
> dispense with it.
> If the NAT44 is the IPv4 client of the scenario chart, the chart can apply
> as well to tethering as to tethering-less. It becomes generic.
>
> RD
>

The use case for not doing  NAT44 is not really the mobile phone case
we have today on my network.

It is more the case of a future mobile phone that allows DHCP-PD or a
FTTH network where a block of IPv6 address is provided to the
CPE/CLAT.  For example, i imagine it will be common for a home
broadband user to use DHCP-PD to get a /60 or /56 -- one prefix.  From
this one delegated prefix, a /64 may be used to simplify the CLAT to
just RFC6145 and removing the need for NAT44.

I hope you don't see the inclusion of  this particular scenario as a
road block to BCP, it is known to work, i posted Cisco configs for it
here before.  There is a balance to be had between "the one scenario"
and creating options that make, within reason,  that allow networks to
deploy what they find most appealing.  For example, the NAT4464
scenario looks, on paper, much less desirable than a NAT464 scenario.
In the real world, there is no difference in the service level AFAIK
... but there may be difference in CPE implementation level of effort.
 For example, i cannot get the NAT446<->NAT64 to work on the Cisco
CLAT but i can get NAT46<->NAT64 to work using today's generally
available implementation.

CB

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 30 Apr 2012 11:03:26 -0500

Hi Cameron,
My questions:

In Section 7.5, you have:
In another cases where the access network does not allow for a
   dedicated translation prefix, the CLAT will do NAT44 such that all
   private IPv4 sourced LAN packets appears from one private IPv4
   address which is statelessly translated to one IPv6 address.

Can you please explain how this works on UEs?
Is it A+P?

I think it needs more clarification (in the draft).

> supports over 85% of the common applications

Is Skype supported?

Is there a CLAT for iPhone?

Regards,

Behcet

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 Apr 2012 09:58:05 -0700

Hi Behcet

> Can you please explain how this works on UEs?

No, it is not A+P it is RFC6145

For example, incoming source IPv4 packets from the LAN 192.168.1.0/24
are NAT44 to the CLAT host address on the LAN of 192.168.1.1.

This allows the CLAT to not have to do NDP for a /96, as discussed on the list.

Then, the CLAT will do RFC6145  so that the IPv4 packets from
192.168.1.1 are translate to the CLAT LAN IPv6 address as described in
RFC 6052

The destination address of the IPv4 packet described above is also
RFC6145 translated to the PREF64 of the PLAT such that it will look
like PREF64+IPv4 address in accordance with RFC 6052 as well.

All of the above, for most cases, is avoided if the application and
service provider are capable of using DNS64... in which case, the only
translation is RFC 6146 at the PLAT

>> supports over 85% of the common applications

No, Skype does not work with IPv6-only.  Yes, Skype does work with 464XLAT.

> Is there a CLAT for iPhone?

No, CLAT is not yet an IETF standard, and even then, who knows what
Apple will do.  They do not pre-announce features.

But, there are working implementations on open platforms such as the
Android Nexus S.

http://dan.drown.org/android/clat/

CB

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 30 Apr 2012 14:32:28 -0500

> 192.168.1.1 are translate to the CLAT LAN IPv6 address as described in

I was asking UE operation. Are you saying that the source address from
each and every UE after NAT44 is 192.168.1.1?

> No, Skype does not work with IPv6-only.

you mean with NAT64?

>Yes, Skype does work with 464XLAT.

Why?

Which apps are in 15% then?

Regards,

Behcet

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 Apr 2012 13:07:23 -0700

Behcet,

> each and every UE after NAT44 is 192.168.1.1?

The exact IP is implementation specific.  But, yes, something like
that.   In a 464XLAT deployment where NAT44 is used in the CLAT, the
NAT44 to NAT46 is an internal function which never appears on the
wire.

>> No, Skype does not work with IPv6-only.

Sorry for being unclear.  Skype, today, does not work on a host that
lacks IPv4 connectivity.

This means Skype does not work on an IPv6-only hos.   Generally,
IPv6-only host use NAT64 / DNS64 services in the context of this
discussion.

>From that, you can conclude that Skype does not work with NAT64, which
is not precisely correct, but usually correct since IPv6-only hosts do
not work with Skype.

The key is that Skype, and any application that uses or signals IPv4
literals, requires IPv4 functionality locally on the host.

>>Yes, Skype does work with 464XLAT.

Skype does work with 464XLAT since 464XLAT provides an IPv4 socket /
address / route to which the Skype program can bind to and send native
IPv4 packets to.

> Which apps are in 15% then?

The 15% of Android apps broken on IPv6-only + NAT64/DNS64 claim is
based on this data set goo.gl/z3j3q

The red highlights applications that fail on IPv6-only network, the
sample suggest that 15% of Android apps fail on an IPv6-only network

The green highlights that all the items that failed now work with an
IPv6-only attachment network when 464XLAT is used.

So, using an IPv6-only access network with standard NAT64/DNS64
results in 15% of Android apps breaking

When 464XLAT is used on Android with an IPv6-only access network (such
as IPv6 PDP), 100% of applications work.

I hope this is now clear.

CB