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

From: [email-masked]
Date: Mon, 06 Aug 2012 21:35:32 -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-06.txt
	Pages           : 19
	Date            : 2012-08-06

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

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

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

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

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

---

From: Masanobu Kawashima <[email-masked]>
Date: Tue, 7 Aug 2012 13:39:07 +0900

v6ops chairs,

We have published draft-ietf-v6ops-464xlat-06.
This draft is simply adding section 2 "BCP Scenario".
Could you please start WGLC?

Thank you for your time and consideration.

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: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 7 Aug 2012 05:53:42 +0000

I'll let the current WGLC run and then open one for 464XLAT.

>> ftp://ftp.ietf.org/internet-drafts/

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Aug 2012 16:39:52 +0200

Hi, Fred,

I agree that adding an applicability statement, as you requested last week, is an approach that improves acceptability of BCP status (as opposed to Informational recommended by some participants in Vancouver).

This statement is currently:
" 2. BCP Scenario					
 This BCP only applies when the following two criteria are present:	
 1. There is an IPv6-only access network that uses stateful translation [RFC6146]	
 2. There are IPv4-only applications or hosts that must communicate across the IPv6-only access network to reach the IPv4 Internet

In my understanding, it should be more complete, e.g. as follows:

" 2. Applicability of 464XLAT				
 This BCP only applies when the following three criteria are present:	
 1. There is an IPv6-only access network that doesn't support DS-lite [RFC6333] but supports NAT64 stateful translation [RFC6146]
 2. There are IPv4-only applications or hosts that must communicate across the IPv6-only access network to reach the IPv4 Internet
 3. The lack of transparency to source-fragmented IPv4 packets that, as recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. have DF=1), is considered acceptable.

Comments welcome.

Regards,
RD

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 7 Aug 2012 15:43:31 +0000

> 3. The lack of transparency to source-fragmented IPv4 packets that, as recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. have DF=1), is considered acceptable.

So you're arguing that we need a comment in this applicability statement regarding each other solution, or just that one? It seems to me that at most (1) might add "to access an IPv4 network" or "to access the IPv4 Internet" - which are different statements. There is no reason to go into what the other options the operator might have chosen might be.

I'll let others comment on your third bullet. Personally, I would not expect the implementation to require fragmentation, but would expect it to use configuration or PMTU to ensure that the packets were small enough.

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Aug 2012 19:23:50 +0200

Le 2012-08-07 à 17:43, Fred Baker (fred) a écrit :

> So you're arguing that we need a comment in this applicability statement regarding each other solution, or just that one?

Just that one (no hidden intention!).

DS-Lite is an  already specified stateful solution for IPv4 customers that have no public addresses to reach the IPv4 Internet across IPv6-only access networks. It hasn't the limitation of item 3.
If there are IPv6-only deployments where NAT64s are available but not DS-Lite, in particular in the short term, 464XLAT is AFAIK better than nothing, and is therefore, as said from the beginning, worth documenting.  
However, if DS-lite is available, using it is AFAIK better practice (more transparent to IPv4, and very simple too in CPE/UEs).

(Something more might be said for stateless solutions, but this is AFAIK out of scope for 464XLAT.)

> It seems to me that at most (1) might add "to access an IPv4 network" or "to access the IPv4 Internet" - which are different statements. There is no reason to go into what the other options the operator might have chosen might be.
> 

a. Applications that send UDP datagrams longer than PMTUs, which is the case of some games AFAIK, have to fragment. (If there would be no such applications, why to have any fragmentation in IPv6?)

b. In case of UE tethering, such applications are not controlled by UEs themselves.

RD

---

From: GangChen <[email-masked]>
Date: Wed, 8 Aug 2012 07:22:19 +0800

Hello Remi and authors,

I'm supporting the BCP status because it is essential to guarantee
multiple compatible implementations.
More comments and proposed texts are inline.

2012/8/8, Rémi Després <[email-masked]>:
>>> I agree that adding an applicability statement, as you requested last
>>> week, is an approach that improves acceptability of BCP status (as
>>> opposed to Informational recommended by some participants in Vancouver).
>>>
>>> 2. There are IPv4-only applications or hosts that must communicate across
>>> the IPv6-only access network to reach the IPv4 Internet
>>>
>>> 1. There is an IPv6-only access network that doesn't support DS-lite
>>> [RFC6333] but supports NAT64 stateful translation [RFC6146]
>>> 2. There are IPv4-only applications or hosts that must communicate across
>>> the IPv6-only access network to reach the IPv4 Internet
>>> 3. The lack of transparency to source-fragmented IPv4 packets that, as
>>> recommended by RFC 4821, MUST NOT be fragmented by the network (i.e. have
>>> DF=1), is considered acceptable.
>>
>> So you're arguing that we need a comment in this applicability statement
>> regarding each other solution, or just that one?
>
> DS-Lite is an  already specified stateful solution for IPv4 customers that
> have no public addresses to reach the IPv4 Internet across IPv6-only access
> networks. It hasn't the limitation of item 3.
> If there are IPv6-only deployments where NAT64s are available but not
> DS-Lite, in particular in the short term, 464XLAT is AFAIK better than
> nothing, and is therefore, as said from the beginning, worth documenting.
> However, if DS-lite is available, using it is AFAIK better practice (more
> transparent to IPv4, and very simple too in CPE/UEs).

I see the fairy decision choosing NAT64 other than DS-lite in 464xlat
because it could provide functional compability with ACL and many
network provisioning facilities, especially in a mobile environment.
Also agree Fred's comments "There is no reason to go into what the
other options the operator might have chosen might be."

>> It seems to me that at most (1) might add "to access an IPv4 network" or
>> "to access the IPv4 Internet" - which are different statements. There is
>> no reason to go into what the other options the operator might have chosen
>> might be.
>>
>> I'll let others comment on your third bullet. Personally, I would not
>> expect the implementation to require fragmentation, but would expect it to
>> use configuration or PMTU to ensure that the packets were small enough.
>
> a. Applications that send UDP datagrams longer than PMTUs, which is the case
> of some games AFAIK, have to fragment. (If there would be no such
> applications, why to have any fragmentation in IPv6?)
>

RFC 4821 says: "It is RECOMMENDED that IPv4 implementations use a
strategy that mimics IPv6 functionality. When an application sends
datagrams that are larger than the effective Path MTU, they SHOULD be
fragmented to the Path MTU in the host IP layer even if they are
smaller than the MTU of the first link, directly attached to the host.
The DF bit SHOULD be set on the fragments, so they will not be
fragmented again in the network."  If I understood correctly, that
would result in the case "DF=1 MF=1".

Some discussions reported that is a rare case. AFAIK, there were no
obsevered impacts to network so far. Therefore, I guess that should
not be a stumbling block to BCP if we could identify the problem
properly.

Considering above, I'm trying to propose some texts to fix the gap.
Hope that could help.

"
This BCP is applied because 464xlat leverages available host/router
implementations by combining existing and well-known stateful protocol
translation [RFC6146] and stateless protocol translation [RFC6145].
It's helpful to promote the mechanism introduction as an immediate
instantiation, which is justified as a good applicability to BCP
status [RFC2026]. On the other hand, it's worth to be noted that the
processing involved in the framework may not achieve fully reversible
translations, e.g. DF bits may not kept in the case of DF=1 and MF=1.
The impacts of those cases are likely to be identified as a long-term
issue, since it's reported that the cases occurred rarely and not
observed as negative effects in practice.

This BCP can be applied when the following two criteria are present:

       1.  There is an IPv6-only access network that uses stateful
           translation [RFC6146]

       2.  There are IPv4-only applications or hosts that must communicate
           across the IPv6-only access network to reach the IPv4 Internet
"

Many thanks

Gang

---

From: Maoke <[email-masked]>
Date: Wed, 8 Aug 2012 11:42:56 +0900

hi Remi,

2012/8/7 Rémi Després <[email-masked]>

> week, is an approach that improves acceptability of BCP status (as opposed
> to Informational recommended by some participants in Vancouver).
>

> DF=1), is considered acceptable.

as a translation-fashion solution, i don't think the DF transparency is of
the design goal. and i have observed that:

#1. the RFC6146 has proposed the required behavior regarding the fragment
handling(sec 3.4), leaving the detailed method to the implementation that
includes the reassembly before translating. it is also stated that the size
of outgoing packets as well and the potential need for fragmentation is
done according to the behavior defined in RFC6145.

#2. even if any host behind CLAT is implemented complaint with RFC4821,
please note that the RFC6145 states "the translator should not add fragment
header" "if the DF bit is set and the packet is not a fragment (i.e., the
More Fragments (MF) flag is not set and the Fragment Offset is equal to
zero)", and confirms "there is a need to add a Fragment Header" means "the
DF bit is not set or the packet is a fragment", therefore, the case with
(DF=1 && (MF=1 || Offset is not zero) will be translated WITH fragment
header, indicating the packet could be further fragmented after being
translated back to IPv4 (with DF=0)  by PLAT. sure this doesn't ensure DF=1
not changed through the 464xlat domain but it works even in the case
RFC4821 host makes out DF=MF=1. again the full DF transparency, to my
understanding, is not the design goal of 464xlat.

therefore adding the text in response to RFC4821 is not necessary. i
support the BCP status of the doc with current applicability statement.

- maoke

---

From: Maoke <[email-masked]>
Date: Wed, 8 Aug 2012 11:51:52 +0900

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

> transparent to IPv4, and very simple too in CPE/UEs).

i may say they are different practices but stating DS-lite *more
transparent to ipv4* is confusing. as there is a CGN, it is not end-to-end
transparent anyway.

> "to access the IPv4 Internet" - which are different statements. There is no
> reason to go into what the other options the operator might have chosen
> might be.
> >
> a. Applications that send UDP datagrams longer than PMTUs, which is the
> case of some games AFAIK, have to fragment. (If there would be no such

true that some games that poorly designed often do the big datagram. on the
other hand, there is no problem that these UDP datagrams will be fragmented
in the RFC6145/6146 combination. may you identify what the concern is?

- maoke

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Aug 2012 09:13:18 +0200

Hi, Gang,

Thanks for your comments.
More inline.

> other options the operator might have chosen might be."

Understood. With the addition I propose: 
- I no longer object to BCP
- Where NAT64 is supported and DS-Lite isn't, this BCP recommends 464XLAT
This, I think, covers your need. 

> fragmented again in the network."  

> If I understood correctly, that

Yes.
And also, to be complete, the case "DF=1 and Offset>0".

> not be a stumbling block to BCP if we could identify the problem

Same view.  

> observed as negative effects in practice.

I don't think this last sentence has rigorous enough logic in face of the fact that RFC4821 is standard track.
An alternative to proposed item 3 could be:
" 3. The fact that IPv4 packets that are fragmented by sources, and not fragmentable in the network as recommended by [RFC4821], become fragmentable again is considered of limited enough consequence and considered rare enough and to be consciously accepted. (Packets sourced with DF=1 and MF=1 and/or Offset>0 become MF=0 after 464 translation)."   

Kind regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Aug 2012 09:23:44 +0200

Hi, Maoke,

2012-08-08 04:51, Maoke :

> i may say they are different practices but stating DS-lite *more transparent to ipv4* is confusing. as there is a CGN, it is not end-to-end transparent anyway. 

Well, "more transparent" doesn't mean "fully transparent". 
In any case, I propose to explain in what it is so, thus avoiding confusion.

> true that some games that poorly designed often do the big datagram. on the other hand, there is no problem that these UDP datagrams will be fragmented in the RFC6145/6146 combination. may you identify what the concern is? 

The only problem I see is that incompatibility with the logic recommended by RFC 4821 needs to be signaled.
No objection to accepting this fact, but objection to hiding it.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Wed, 8 Aug 2012 16:49:49 +0900

dear Remi,

>> > So you're arguing that we need a comment in this applicability
>> statement regarding each other solution, or just that one?
>>
>> DS-Lite is an  already specified stateful solution for IPv4 customers
>> that have no public addresses to reach the IPv4 Internet across IPv6-only
>> access networks. It hasn't the limitation of item 3.
>> > It seems to me that at most (1) might add "to access an IPv4 network"
>> or "to access the IPv4 Internet" - which are different statements. There is
> true that some games that poorly designed often do the big datagram. on
> the other hand, there is no problem that these UDP datagrams will be
> fragmented in the RFC6145/6146 combination. may you identify what the
> concern is?
>
>

i think RFC4821 is more of recommending a host implementation that mimics
ipv6's host fragmentation behavior by setting DF=1 no matter the anyway.
CLAT RFC6145 can handle such DF=1 / MF=1 or offset > 0 but the only problem
is it cannot keep the intention of the host making the DF=1.

i do agree to signal such an observation. i only don't think it should be
in the applicability statement because the transparency of DF is not the
design goal. :)

- maoke

---

From: GangChen <[email-masked]>
Date: Wed, 8 Aug 2012 15:53:54 +0800

2012/8/8, Rémi Després <[email-masked]>:
>>>>> across
>>>>> across
>>>> statement
>>> that

It's great to hear that.
Thanks

>
>>> (Something more might be said for stateless solutions, but this is AFAIK
>>> out
>>> of scope for 464XLAT.)
>>>
>>>
>>>> or
>>> case
> " 3. The fact that IPv4 packets that are fragmented by sources, and not
> fragmentable in the network as recommended by [RFC4821], become fragmentable
> again is considered of limited enough consequence and considered rare enough
> and to be consciously accepted. (Packets sourced with DF=1 and MF=1 and/or
> Offset>0 become MF=0 after 464 translation)."

Rigorous statements are always desirable
I made second try on texts proposal to converge the discussion as following.

The general logic is to state the observation of BCP in advance. And
then, BCP scenario is described.
Is that acceptable to you?
Same question is also to authors.

===> Proposed texts

This BCP is applied because 464xlat leverages available host/router
implementations by combining existing and well-known stateful protocol
translation [RFC6146] and stateless protocol translation [RFC6145].
It's helpful to promote the mechanism introduction as an immediate
instantiation, which is justified as a good applicability to BCP
status [RFC2026]. On the other hand, it's worth to be noted that the
processing involved in the framework may not achieve fully reversible
translations, e.g. packets sourced with DF=1 and MF=1 and/or Offset>0
become MF=0 after 464 translation. The fact that IPv4 packets that are
fragmented by sources, and not fragmentable in the network as
recommended by [RFC4821], become fragmentable again is considered of
limited enough consequence and rare enough and to be consciously
accepted.

In regards to above observation, this BCP can be applied when the
following two criteria are present:

===> the end

Many thanks

Gang

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Aug 2012 12:29:24 +0200

>           across the IPv6-only access network to reach the IPv4 Internet

a. Concerning DF bit, this works for me, thanks.

b. As also discussed, the applicability statement should clarify that, in access networks where both NAT64 and DS-Lite are available, using DS-Lite should be recommended (better IPv4 transparency).
For this, adding "and not DS-Lite [RFC6333]" at the end of item 1 would be enough for me.
Accepted?

RD

---

From: GangChen <[email-masked]>
Date: Wed, 8 Aug 2012 23:47:57 +0800

2012/8/8, Rémi Després <[email-masked]>:

> b. As also discussed, the applicability statement should clarify that, in
> access networks where both NAT64 and DS-Lite are available, using DS-Lite
> should be recommended (better IPv4 transparency).

The comment in this applicability statement is only regarding 464xlat.
As commented earlier "There is no reason to go into what the other
options the operator might have chosen might be. "
IMHO, the proposed statement above already covered your needs.
As a contributor to this work, this is only my personal view on that.
I guess authors can use at the discretion in order to make a rigorous
statement.

Many thanks

Gang

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 8 Aug 2012 16:57:44 +0000

> For this, adding "and not DS-Lite [RFC6333]" at the end of item 1 would be enough for me.

</chair>
As I said earlier, it is beyond me why an applicability statement or a technical description of one technology is constrained to discuss another.

Let me repeat something that has been pointed out by others in this thread. By inserting a tunnel here - an IP/IP or GRE static tunnel, 4rd, ds-lite, an MPLS LSP, or whatever other kind of tunnel might come to mind - one does not provide an end to end IPv4 infrastructure. The solution can translate to IPv6 and back to IPv4, or it can translate IPv4 to IPv4 at one end of the tunnel or another, but one does not avoid translation of IPv4 packets. The only way one avoids translation - at all - is to send native IPv6 packets and deliver them to one's destination. That's kind of the point here, as Cameron pointed out in the talk last week.

For my money, this document should be constrained to talking about the 464XLAT solution and the cases in which those providers using it find it useful. Any other discussion, in my opinion, mostly confuses the discussion.

<chair>
At this point, in the opinion of this chair, any textual changes in the document should be for the purposes of clarifying the 464XLAT deployment strategy and its uses of the technologies it specifies, or the operational utility of it. Discussion of technologies that would not be used in a 464XLAT network is out of place.

---

From: GangChen <[email-masked]>
Date: Thu, 9 Aug 2012 10:13:48 +0800

Hello authors,

That is a tentative text proposal after several rounds of discussions.

===> Proposed texts

become DF=0 after 464 translation. The fact that IPv4 packets that are

===> the end

Please kindly take that to your reference.

Many thanks

Gang

2012/8/9, Fred Baker (fred) <[email-masked]>:
> As I said earlier, it is beyond me why an applicability statement or a
> technical description of one technology is constrained to discuss another.
>
> Let me repeat something that has been pointed out by others in this thread.
> By inserting a tunnel here - an IP/IP or GRE static tunnel, 4rd, ds-lite, an
> MPLS LSP, or whatever other kind of tunnel might come to mind - one does not
> provide an end to end IPv4 infrastructure. The solution can translate to
> IPv6 and back to IPv4, or it can translate IPv4 to IPv4 at one end of the
> tunnel or another, but one does not avoid translation of IPv4 packets. The
> only way one avoids translation - at all - is to send native IPv6 packets
> and deliver them to one's destination. That's kind of the point here, as
> Cameron pointed out in the talk last week.
>
> For my money, this document should be constrained to talking about the
> 464XLAT solution and the cases in which those providers using it find it
> useful. Any other discussion, in my opinion, mostly confuses the
> discussion.
>
> <chair>
> At this point, in the opinion of this chair, any textual changes in the
> document should be for the purposes of clarifying the 464XLAT deployment
> strategy and its uses of the technologies it specifies, or the operational
> utility of it. Discussion of technologies that would not be used in a
> 464XLAT network is out of place.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 9 Aug 2012 06:23:28 +0000 (UTC)

> </chair>
....
> For my money, this document should be constrained to talking about the 464XLAT solution and the cases in which those providers using it find it useful. Any other discussion, in my opinion, mostly c…

s/providers/people/  I am not a provider, I still find it useful.

> At this point, in the opinion of this chair, any textual changes in the document should be for the purposes of clarifying the 464XLAT deployment strategy and its uses of the technologies it specifi…

Let me add what might have been forwarded in some ways.  Currently the BCP
Scenario only talks about IPv6-only *access* networks.  Now depending
on how you define "access" this might be true.

However running an application requiring IPv4 sockets on my IPv6-only
desktop kernel does not mean that my local network might not otherwise
be dual stacked but just that my end-node is IPv6-only transport and this
technology should allow me to do the translation purely in user space.

So another use case is

   There are IPv4-only applications running on a node with an IPv6-only
   kernel wanting to communicate with other (IPv4) nodes.

IMHO this is currently the only transition technology allowing me to
do this, thus helping to push the IPv6-only boundry further out without
killing legacy applications.  Now this is the developers point of view
and not the operators point of view.  I am not asking for a complete
substitution of "access" in the draft;)  I just want to kill any
further tunneling discussions etc.  They simply are not applicable/do
not work in this case anymore.  Once I can prove my point with a
working implementation I'll be happy to update this one, but this
needs to go out and we need to move on, so I'll postpone.

/bz

PS: I'll send a diff latest during the weekend as there are a couple
of proof reading things and inconsistencies in exmaples as well as
invalid IPv6 addresses but this is only editorial not functional
changes.

-- 
Bjoern A. Zeeb                                 You have to have visions!
          Stop bit received. Insert coin for new address family.

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Aug 2012 11:11:42 +0200

> Let me repeat something that has been pointed out by others in this thread. By inserting a tunnel here - an IP/IP or GRE static tunnel, 4rd, ds-lite, an MPLS LSP, or whatever other kind of tunnel m…

Strictly speaking, the second sentence isn't accurate because a stateless v4/v6 tunneling solution, e.g. that being currently specified in Softwire, does provide e2e v4 service. (No e2e way to notice that part of the path includes one or several IPv4 tunnels over IPv6.)

OTOH, I agree that, in the limited context of STATEFUL solutions (i.e. including port translation), e2e transparency is never complete, and that DS-Lite is in this category. 
The only point point here is that DS-Lite always preserves DF bits, and thus maintains compatibility with RFC 4821, while 464XLAT doesn't. 

> For my money, this document should be constrained to talking about the 464XLAT solution and the cases in which those providers using it find it useful. Any other discussion, in my opinion, mostly c…

Note that DNS64 is discussed in the draft although it isn't part of the 464XLAT specification. The criterion to mention or not a different technology seems therefore to be more "is it useful" than "should never be done", which makes sense.

Letting readers believe that 464XLAT is THE best choice even where service providers choose to support not only NAT64 CGN but also DS-Lite remains misleading AFAIK. 

I can't understand why it would be such a big deal to clarify that, even in the limited context of stateful solutions, it is only for networks that don't support more transparent transition solutions that 464XLAT is THE recommended solution. 

Regards,
RD

---

From: GangChen <[email-masked]>
Date: Thu, 9 Aug 2012 18:04:27 +0800

Hello Remi,

2012/8/9, Rémi Després <[email-masked]>:
>> Let me repeat something that has been pointed out by others in this
>> thread. By inserting a tunnel here - an IP/IP or GRE static tunnel, 4rd,
>> ds-lite, an MPLS LSP, or whatever other kind of tunnel might come to mind
>> - one does not provide an end to end IPv4 infrastructure. The solution can
>> translate to IPv6 and back to IPv4, or it can translate IPv4 to IPv4 at
>> one end of the tunnel or another, but one does not avoid translation of
>> IPv4 packets. The only way one avoids translation - at all - is to send
>> native IPv6 packets and deliver them to one's destination. That's kind of
>> the point here, as Cameron pointed out in the talk last week.
>
> Strictly speaking, the second sentence isn't accurate because a stateless
> v4/v6 tunneling solution, e.g. that being currently specified in Softwire,
> does provide e2e v4 service. (No e2e way to notice that part of the path
> includes one or several IPv4 tunnels over IPv6.)

I like the statement as you said earlier, that is "more transparent".
NAT44 is still needed on CPE even in encapsulation case.

> OTOH, I agree that, in the limited context of STATEFUL solutions (i.e.
> including port translation), e2e transparency is never complete, and that
> DS-Lite is in this category.
> The only point point here is that DS-Lite always preserves DF bits, and thus
> maintains compatibility with RFC 4821, while 464XLAT doesn't.

RFC4821 argument was already documented in the proposal. I guess that
is sufficient to signal the fact. Adding much may not help the
discussion IMHO.

> Note that DNS64 is discussed in the draft although it isn't part of the
> 464XLAT specification.

DNS64 is closely related to and discussed in RFC6146. Therefore, it
can't be a justification we need to do more on different technology.

>The criterion to mention or not a different
> technology seems therefore to be more "is it useful" than "should never be
> done", which makes sense.
>
> Letting readers believe that 464XLAT is THE best choice even where service
> providers choose to support not only NAT64 CGN but also DS-Lite remains
> misleading AFAIK.

How the misleading should be? We even do 4rd to overcome ACL
incompatibilities in DS-Lite kind of solution. That is a trade-off
actually, i.e. "more transparent" vs "more compabilities". It's worth
another draft to argue that. I really want the draft focus specific
discussion on 464xlat features.

> I can't understand why it would be such a big deal to clarify that, even in
> the limited context of stateful solutions, it is only for networks that
> don't support more transparent transition solutions that 464XLAT is THE
> recommended solution.

Considering above, I hope you could accept and let us move-on

Many thanks

Gang

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Aug 2012 15:11:08 +0200

Dear Gang,

None of what follows convinces me that the clarification I see as necessary is against anyone's need.
Besides, none of what I explained seems to convince any key supporter of the 464XLAT proposal that this clarification is acceptable.
How to proceed is, I suppose, a matter for chairs to decide.

Having said what had IMHO to be said, I don't plan to add anything unless some new statement is made that is AFAIK invalid. 

Regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Aug 2012 09:57:15 +0900

On Thu, Aug 9, 2012 at 6:11 PM, Rémi Després <[email-masked]>wrote:

> I can't understand why it would be such a big deal to clarify that, even
> in the limited context of stateful solutions, it is only for networks that

I believe we all agree that 464xlat is suboptimal in terms of transparency
and that other technologies provide better transparency. I believe we also
agree that this is not a strict requirement for 464xlat because many of the
target scenarios are networks that already run carrier-operated NAT, which
of course is not transparent. The only thing we disagree on is what the
"best" in "best practice" should refer to. Right?

With that in mind - if we said that the "best" in "best" practice refers to
"the best way of running IPv4 over IPv6 when combining stateful and
stateless NAT64?", or "the best way of running IPv4 over IPv6 in networks
that cannot support encapsulation"?

Could we agree on that?

Cheers,
Lorenzo

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 9 Aug 2012 19:09:52 -0700

>
>
> I believe we all agree that 464xlat is suboptimal in terms of
transparency and that other technologies provide better transparency. I
believe we also agree that this is not a strict requirement for 464xlat
because many of the target scenarios are networks that already run
carrier-operated NAT, which of course is not transparent. The only thing we
disagree on is what the "best" in "best practice" should refer to. Right?
>
> With that in mind - if we said that the "best" in "best" practice refers
to "the best way of running IPv4 over IPv6 when combining stateful and
stateless NAT64?", or "the best way of running IPv4 over IPv6 in networks
that cannot support encapsulation"?
> Could we agree on that?

Afaik, the draft says  that in section 2.

The current text in the draft is very concise and exact about where the bcp
applies. I see no need for any change.

If somebody wants to write different draft that establishes a pecking order
such as DS > MAP-E  > ds-lite >  464xlat. ....

They may do that.  464xlat is not the place for establishing that context
for the global set of solutions.

The current scope of the bcp is only networks that have stateful nat64 and
is very clear in several places that this is a "limited" ipv4 service

CB

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Aug 2012 08:19:09 +0200

Le 2012-08-10 à 02:57, Lorenzo Colitti a écrit :

> On Thu, Aug 9, 2012 at 6:11 PM, Rémi Després <[email-masked]> wrote:
> I believe we all agree that 464xlat is suboptimal in terms of transparency and that other technologies provide better transparency. I believe we also agree that this is not a strict requirement for 464xlat because many of the target scenarios are networks that already run carrier-operated NAT, which of course is not transparent. The only thing we disagree on is what the "best" in "best practice" should refer to. Right?
> 
> With that in mind - if we said that the "best" in "best" practice refers to "the best way of running IPv4 over IPv6 when combining stateful and stateless NAT64?", or "the best way of running IPv4 over IPv6 in networks that cannot support encapsulation"?

The second one does cover my point.

> Could we agree on that?

Yes, AFAIAC.
Could be improved IMHO with "does not support" instead "cannot support", but acceptable as is.

Thanks,
RD

---

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

Le 2012-08-10 à 04:09, Cameron Byrne a écrit :

> The current text in the draft is very concise and exact about where the bcp applies. I see no need for any change.
> 
> If somebody wants to write different draft that establishes a pecking order such as DS > MAP-E  > ds-lite >  464xlat. ....
> 

Did anyone suggested to include MAP-E???
Lorenzo's proposal Nb 2 is OK.
RD
 
> They may do that.  464xlat is not the place for establishing that context for the global set of solutions.
> 
> The current scope of the bcp is only networks that have stateful nat64 and  is very clear in several places that this is a "limited" ipv4 service
> 
> CB
> 
> > Cheers,
> > Lorenzo
> >

---

From: t.petch <[email-masked]>
Date: Fri, 10 Aug 2012 12:28:35 +0100

----- Original Message -----
From: "Bjoern A. Zeeb" <[email-masked]>
To: "v6ops WG" <[email-masked]>
Cc: "V6ops Chairs" <[email-masked]>
Sent: Thursday, August 09, 2012 7:23 AM

> > For my money, this document should be constrained to talking about
the 464XLAT solution and the cases in which those providers using it
find it useful. Any other discussion, in my opinion, mostly confuses the
discussion.
> > At this point, in the opinion of this chair, any textual changes in
the document should be for the purposes of clarifying the 464XLAT
deployment strategy and its uses of the technologies it specifies, or
the operational utility of it. Discussion of technologies that would not
be used in a 464XLAT network is out of place.
> on how you define "access" this might be true.

For me, and how I see "access" used, access is clearly the wrong term:-(

I see access networks as giving access to the Internet, at either end,
so in this I-D it is the v4p and v4g networks that are access (although
access networks could of course be v6 instead).  The use of "access"
here gives me the flavour that I am sitting in a Data Centre, viewing
the world from there, and the access network is providing access to the
Data Centre from the world at large; and that seems wrong.

Tom Petch

> Bjoern A. Zeeb

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 10 Aug 2012 11:53:36 +0000

I agree with Cameron.

Cheers,
Rajiv

Sent from my Phone

On Aug 9, 2012, at 10:10 PM, "Cameron Byrne" <[email-masked]<mailto:[email-masked]>> wrote:

On Aug 9, 2012 5:58 PM, "Lorenzo Colitti" <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Thu, Aug 9, 2012 at 6:11 PM, Rémi Després <[email-masked]<mailto:[email-masked]>> wrote:
>>

CB

> [email-masked]<mailto:[email-masked]>

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 10 Aug 2012 12:15:56 +0000

Did we already conclude that this is a BCP and not Informational? We should just put it in the latter category and move on/progress.

Cheers,
Rajiv

Sent from my Phone

On Aug 9, 2012, at 8:57 PM, "Lorenzo Colitti" <[email-masked]<mailto:[email-masked]>> wrote:

Could we agree on that?

Cheers,
Lorenzo

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 10 Aug 2012 07:25:53 -0700

On Aug 10, 2012 5:16 AM, "Rajiv Asati (rajiva)" <[email-masked]> wrote:
>
> Did we already conclude that this is a BCP and not Informational? We
should just put it in the latter category and move on/progress.

Yes, afaik, the chairs have accepted bcp status and have accepted the bcp
scenario text.

The chairs also direct the WG to move on to any remainig technical issuess.

http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html

CB

> Cheers,
> Rajiv
>
> Sent from my Phone
>
> On Aug 9, 2012, at 8:57 PM, "Lorenzo Colitti" <[email-masked]> wrote:
>
>>> I can't understand why it would be such a big deal to clarify that,
even in the limited context of stateful solutions, it is only for networks
that don't support more transparent transition solutions that 464XLAT is
THE recommended solution.

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Aug 2012 18:00:05 +0200

Le 2012-08-10 à 16:25, Cameron Byrne a écrit :

> Yes, afaik, the chairs have accepted bcp status and have accepted the bcp scenario text.
> 

After that, Lorenzo proposed an approach, which I approved, to resolve the last issue I had raised.
If the chairs also agree, all is AFAIK OK for the draft to proceed without objection as BCP.
Regards,`
RD

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 10 Aug 2012 09:39:38 -0700

> If the chairs also agree, all is AFAIK OK for the draft to proceed without

Rémi,

It sounds like you are deferring to the chairs.

I too will defer to the chairs, since my focus is moving forward.

The chairs have already made their position known, and they may
re-open this issue.

You and Lorenzo have supplied input to the chairs.

My input to the chairs is that there should be no changes required of
the current text.  In very basic logical terms the text currently says

X = RFC 6146

IF  (X) then 464XLAT is BCP for providing IPv4 service to IPv4-only
hosts and apps on an IPv6-only access network.

Your original proposal and more or less Lorenzo's proposal

Y = DS-lite

IF (X and NOT Y)  then BCP  for providing IPv4 service to IPv4-only
hosts and apps on an IPv6-only access network

The difference between "only X" and "X and not Y" is that there must
be a scenario where X and Y both occur.   I do not believe that is the
case that X and Y will occur together so there is no need to
complicated the document with this.  And, your meaning, which i
believe is to say that tunneling is better than translation, is
already documented in the IETF (RFC 4213, others?)

As i said before, it seems like the aim is to create a pecking order
of transition solutions.  If you want to do that, that is the scope of
a different draft.

CB

---

From: Ole Trøan <[email-masked]>
Date: Fri, 10 Aug 2012 19:00:11 +0200

Cameron,

> of transition solutions.  If you want to do that, that is the scope of

+1.

I think 464XLAT should be standing on its own, and given the plethora of IPv4 life extension mechanisms then it is quite unlikely that we'll reach consensus on that pecking order any time soon. I know I disagree with Y above at least. ;-)

cheers,
Ole

---

From: joel jaeggli <[email-masked]>
Date: Fri, 10 Aug 2012 10:05:39 -0700

>>> should just put it in the latter category and move on/progress.
We did, there were opinions voiced in the meeting and on the mailing list.

  A raising of hands was taken.

In conjunction with the area director, we requested that the draft be 
resubmitted with an applicability statement that made it clear when it 
was expected to be appropiate  and an intended status of BCP.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 10 Aug 2012 17:43:05 +0000

Got it. Thanks. And assuming that this is the applicability statement, I
am ok with it to move forward.

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-06#section-2

Cheers,
Rajiv

-----Original Message-----
From: Joel jaeggli <[email-masked]>
Date: Friday, August 10, 2012 1:05 PM
To: Cameron Byrne <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt

>>>> After that, Lorenzo proposed an approach, which I approved, to
>>>>resolve the
>>>> last issue I had raised.
>>>> If the chairs also agree, all is AFAIK OK for the draft to proceed
>>>>without
>>>> objection as BCP.
>>>> Regards,`
>>>> RD
>>>>
>> Rémi,
>>

---

From: t.petch <[email-masked]>
Date: Fri, 10 Aug 2012 19:38:22 +0100

Something different and a bit lighter:-)

s.4  "PLAT:   PLAT is Provider side translator(XLAT) that complies with
           [RFC6146].  It translates N:1 global IPv6 packets to global
           IPv4 packets, and vice versa."
Is that really N:1 packets?

s.6.1 "The private IPv4 host on this diagram "
which is the private host?  OK I worked out that the host on the left
had the private addresses, but this could be clearer
'The private IPv4 host on the left hand side of this diagram '
or
'The host on this diagram with the private IPv4 addresses '

and the first occurrences of PLAT, CLAT and UE I would like to see
expanded.

Tom Petch

----- Original Message -----
From: "Cameron Byrne" <[email-masked]>
To: "Rémi Després" <[email-masked]>
Cc: "v6ops WG" <[email-masked]>; "V6ops Chairs"
<[email-masked]>
Sent: Friday, August 10, 2012 5:39 PM
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt

On Fri, Aug 10, 2012 at 9:00 AM, Rémi Després <[email-masked]>
wrote:
> After that, Lorenzo proposed an approach, which I approved, to resolve
the
without

Rémi,

X = RFC 6146

Y = DS-lite

CB

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 10 Aug 2012 13:13:02 -0700

Thanks Tom, we will make these updates

> Is that really N:1 packets?

s/packets/addresses

> 'The host on this diagram with the private IPv4 addresses '

We will change it to 'The host on this diagram with the private IPv4 addresses '

> and the first occurrences of PLAT, CLAT and UE I would like to see

Good idea, will do.

CB

---

From: Rémi Després <[email-masked]>
Date: Sat, 11 Aug 2012 09:14:54 +0200

Cameron, 

Since the point made doesn't seem clear enough, here is another try.

- 464XLAT as best practice where providers offer NAT64 as their ONLY IPv4 support across their access networks: agreed. 
- 464XLAT declared best practice independently of OTHER IPv4 support providers may offer across their access networks, in addition to NAT64-CGN: disagreed.

If a rough consensus is nevertheless declared that ignores this, whatever the reasons, I want to be clearly out of it.

Your key argument below is that no provider would realistically support both 464-CGN and DS-Lite, but this isn't right AFAIK. 
NAT64 is a solution for "IPv6-only clients to contact IPv4 servers" [RFC6146], and DS-Lite a solution for IPv4 clients to reach NAT44-CGNs across IPv6-only access networks such that "communications between end-nodes stay within their address family" [RFC6333]. Satisfying both needs does make sense. 

You object to what you see as a pecking order if, for example, 464XLAT is said to be "the best way of running IPv4 over IPv6 in networks that cannot support encapsulation". But the word "best" in "BCP" is per se expressing some order. Current text implicitly asserts that using 464XLAT IS better than using DS-Lite where both are available. This isn't acceptable AFAIAC. 
Note that I agree that it isn't necessary, in a 464XLAT RFC, to tell, explicitly or implicitly, which one is best practice where 464XLAT coexists with DS-Lite: it can be left unspecified. 

FWIW,  
RD

---

From: GangChen <[email-masked]>
Date: Sat, 11 Aug 2012 23:59:52 +0800

2012/8/11, Rémi Després <[email-masked]>:
> - 464XLAT as best practice where providers offer NAT64 as their ONLY IPv4
> support across their access networks: agreed.
> - 464XLAT declared best practice independently of OTHER IPv4 support
> providers may offer across their access networks, in addition to NAT64-CGN:
> disagreed.
>
> If a rough consensus is nevertheless declared that ignores this, whatever
> the reasons, I want to be clearly out of it.
>
> Your key argument below is that no provider would realistically support both
> 464-CGN and DS-Lite, but this isn't right AFAIK.
> NAT64 is a solution for "IPv6-only clients to contact IPv4 servers"
> [RFC6146], and DS-Lite a solution for IPv4 clients to reach NAT44-CGNs
> across IPv6-only access networks such that "communications between end-nodes
> stay within their address family" [RFC6333]. Satisfying both needs does make
> sense.

The communication model is similar but incentive is different I guess.
DS-Lite is built on the dual-stack model. The target is to guarantee
communication experiences within same address family across different
family. 464xlat adopts IPv6-only model. It aims to serve LIMITED ipv4
service. RFC6180 made really clear statements for each model (see
section 4.3 and 4.4), I guess we don't need to argue that here. So,
why not use it to get rid of confusions.

Item 1 could be clearer as

      1.  There is an IPv6-only Deployment [RFC6180] that uses stateful
       translation [RFC6146]

> You object to what you see as a pecking order if, for example, 464XLAT is
> said to be "the best way of running IPv4 over IPv6 in networks that cannot
> support encapsulation". But the word "best" in "BCP" is per se expressing
> some order. Current text implicitly asserts that using 464XLAT IS better
> than using DS-Lite where both are available. This isn't acceptable AFAIAC.
> Note that I agree that it isn't necessary, in a 464XLAT RFC, to tell,
> explicitly or implicitly, which one is best practice where 464XLAT coexists
> with DS-Lite: it can be left unspecified.
>
> FWIW,
> RD
>
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Aug 2012 09:41:36 +0200

>> Since the point made doesn't seem clear enough, here is another try.

(*)

>> 464-CGN and DS-Lite, but this isn't right AFAIK.

(**)

>      1.  There is an IPv6-only Deployment [RFC6180] that uses stateful

The point is that an IPv6-only deployment with both a NAT-64-CGN and a DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable deployment (see (**) above).  It is inappropriate, in this case, to write that using NAT64 is necessarily best.
- This point isn't covered by words you propose.
- I can't see what would be wrong (besides NIH) in something like:
"1. There is an IPv6-only access network that uses stateful translation [RFC6146] as its sole transition solution for IPv4 via IPv6."
=> (*) above is confirmed.

Regards,
RD

---

From: GangChen <[email-masked]>
Date: Mon, 13 Aug 2012 16:39:14 +0800

2012/8/13, Rémi Després <[email-masked]>:
> The point is that an IPv6-only deployment with both a NAT-64-CGN and a
> DS-Lite-AFTR, both at its border to IPv4 Internet, is a reasonable
> deployment (see (**) above).  It is inappropriate, in this case, to write
> that using NAT64 is necessarily best.

Hope you may consider it again.

My point here is
- The reference of RFC6180 gives audients a very clear context, in
which NAT64 is the major transition solution (That was already
documented section 4.4 in RFC6180; OTOH, DS-lite was described in
section 4.3. Very explicit: two different cases here)
=>I guess that covers your needs

- IPv6-only deployment in RFC6180 perfectly matches 464xlat target
scenarios. This would not complicate the document with additional
scenario justification, but help  the clarification.
=>I guess that covers author needs

So why not adopt RFC6180?

> "1. There is an IPv6-only access network that uses stateful translation
> [RFC6146] as its sole transition solution for IPv4 via IPv6."

The logic seems to me you are using one technology to pick BCP. I
guess we are discussing the scenario picking BCP

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Aug 2012 11:37:21 +0200

> So why not adopt RFC6180?

"IPv6-only deployment" as defined in RFC6180 shouldn't be taken IMHO as a clarifying term for 464XLAT because section 4.4  of this RFC is particularly hard to decode. It can be understood that, in one of its IPv6-only domains, all applications are IPv6-only, so that 464XLAT support of IPv4-only applications is out of scope.

> guess we are discussing the scenario picking BCP

Not understood.

RD

---

From: GangChen <[email-masked]>
Date: Mon, 13 Aug 2012 18:31:35 +0800

2012/8/13, Rémi Després <[email-masked]>:
>>>>> Your key argument below is that no provider would realistically
>>>>> support
>>>>> both
>>>>> stay within their address family" [RFC6333]. Satisfying both needs
>>>>> does
>>>>> make
>>>>> sense.
>>>
>>>
> "IPv6-only deployment" as defined in RFC6180 shouldn't be taken IMHO as a
> clarifying term for 464XLAT because section 4.4  of this RFC is particularly
> hard to decode.

IMHO, RFC6180 is well documented. But I would like to hear other opinions.

>It can be understood that, in one of its IPv6-only domains,
> all applications are IPv6-only, so that 464XLAT support of IPv4-only
> applications is out of scope.

No. The last paragraph of RFC6180 section 4.4 explicitly described the
challenge how to support "IPv4 referrals", which makes application is
IPv6-incapable. Especially, linking to [IPv6-only-experience] even
highlights the significance. 464XLAT is indeed in the scope.

>> guess we are discussing the scenario picking BCP

The section 2 supposed to make applicability statement to the scenario
which gives operational guidance. The scenario to me is a term
independent with a particular technology, like RFC6180 documented
"Native Dual Stack", "IPv6-Only Core Network", "IPv6-Only Deployment"
and etc. Those terms is well understood in the operational context.
Adding second half of texts give an impression we do 464xlat because
of one particular technology. The sense of operational guidance is
somehow weakening imho. But I'm open to hear other opinions as well.

BRs

Gang

>>>>>>> Yes, afaik, the chairs have accepted bcp status and have accepted
>>>>>>> the
>>>>>>> bcp
>>>>>>> scenario text.
>>>>>>>
>>>>>>> resolve

---

From: joel jaeggli <[email-masked]>
Date: Mon, 13 Aug 2012 08:09:08 -0700

>>>       1.  There is an IPv6-only Deployment [RFC6180] that uses stateful
If you eliminate having an ipv4 stack present or active as I think 
Bjoern  noted at the mic, I'm pretty sure encapsulation ceases to be 
feasible path. ds-lite for all it's benefits doesn't allow for that.

While I am happy  to stipulate that ds-lite provides the potential for a 
better experience, if v6only is your goal from the host vantage-point 
it's a non-starter.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 13 Aug 2012 20:32:52 -0700

> >> Your key argument below is that no provider would realistically
support both
> >> stay within their address family" [RFC6333]. Satisfying both needs
does make
> => (*) above is confirmed.

My co-authors and i can accept this.

Is this slight wording change ok?

1. There is an IPv6-only access network that uses stateful  translation
[RFC6146] as the only mechanism for providing ipv4 access.

Regards,

CB

resolve

---

From: Rémi Després <[email-masked]>
Date: Tue, 14 Aug 2012 09:15:01 +0200

Le 2012-08-14 à 05:32, Cameron Byrne a écrit :

> 1. There is an IPv6-only access network that uses stateful  translation [RFC6146] as the only mechanism for providing ipv4 access.
> 
OK for me.
Thanks,
RD

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 14 Aug 2012 10:34:54 +0000 (UTC)

On Thu, 9 Aug 2012, Bjoern A. Zeeb wrote:

A few days later than hoped....

as mentioned previously "access" network might not always be the case but
as said, I'd be willing to ignore that detail unless you want to go through
and do the s/access network/network/g.  I might have done in a few
cases.

Going through the document with that in mind CLAT and PLAT are not really
the right terminonlogy either as at home I am neither a provider nor a
customer for example.  In the 3/4G use case this might be the case.  Again
to be ingored for now.

Please find comments inline.

> Internet Engineering Task Force                              M. Mawatari
> Internet-Draft                          Japan Internet Exchange Co.,Ltd.
> Intended status: BCP                                        M. Kawashima
> Expires: February 8, 2013                       NEC AccessTechnica, Ltd.
>                                                                 C. Byrne
>                                                             T-Mobile USA
>                                                           August 7, 2012
> 
>
>        464XLAT: Combination of Stateful and Stateless Translation
>                       draft-ietf-v6ops-464xlat-06
> 
> Abstract
>

... [RFC6146] ...

>    core and stateless protocol translation RFC 6145 at the edge. 464XLAT

... [RFC6145] ...

>    access service to IPv6-only edge networks without encapsulation.

...

> 1.  Introduction
>
>    The IANA unallocated IPv4 address pool was exhausted on February 3,
>    2011.  Each RIR's unallocated IPv4 address pool will exhaust in the
>    near future.  It will be difficult for many networks to assign IPv4
>    addresses to end users, despite substantial IP connectivity growth
>    required for fast growing edge networks.

Do we need this history lesson in each and every draft/RFC?   It could at
least be shortened to somehting like this:

With the exhaustion of the IPv4 address pools, it will be difficult ...

>
>    This document describes an IPv4 over IPv6 solution as one of the
>    techniques for IPv4 service extension and encouragement of IPv6
>    deployment. 464XLAT is not a one for one replacement of full IPv4

... one-for-one ...

>    functionality.  The 464XLAT architecture only supports IPv4 in the
>    client server model, where the server has global IPv4 address.  This

... has [insert] a [/insert] global ...

>    means it is not fit for IPv4 peer-to-peer communication or inbound
>    IPv4 connections. 464XLAT builds on IPv6 transport and includes full
>    any to any IPv6 communication.

... any-to-any ...

>
>    The 464XLAT architecture described in this document uses IPv4/IPv6
>    translation standardized in [RFC6145] and [RFC6146].  It does not
>    require DNS64 [RFC6147] since an IPv4 host may simply send IPv4
>    packets, including packets to an IPv4 DNS server, which will be
>    translated on the CLAT to IPv6 and back to IPv4 on the PLAT. 464XLAT

Expand CLAT on fist use here.
Expand PLAT on fist use here.

>    networks may use DNS64 [RFC6147] to enable single stateful
>    translation [RFC6146] instead of 464XLAT double translation where
>    possible.  The 464XLAT architecture encourages IPv6 transition by

... encourages [insert] the [/insert] IPv6 ...

>    making IPv4 services reachable across IPv6-only networks and
>    providing IPv6 and IPv4 connectivity to single-stack IPv4 or IPv6
>    servers and peers.
>
>    By combining 464XLAT with BIH [RFC6535], it is also possible to
>    provide single IPv4 to 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.

"done twice"  [remove] legacy [/remove]

> 2.  BCP Scenario

[append] . [/append]

>        across the IPv6-only access network to reach the IPv4 Internet

[append] . [/append]

> 
> 
> 
> 
> 
> 
> 
> Mawatari, et al.        Expires February 8, 2013                [Page 3]
> 
> Internet-Draft                   464XLAT                     August 2012
> 
> 
> 3.  Requirements Language
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
> 
> 
> 4.  Terminology
>
>    PLAT:   PLAT is Provider side translator(XLAT) that complies with
>            IPv4 packets, and vice versa.
>
>    CLAT:   CLAT is Customer side translator(XLAT) that complies with
>            [RFC6145].  It algorithmically translates 1:1 private IPv4
>            packets to global IPv6 packets, and vice versa.  The CLAT
>            function is applicable to a router or an end-node such as a
>            mobile phone.  CLAT SHOULD perform router function to

... . [insert] The [/insert] CLAT ...

>            facilitate packets forwarding through the stateless
>            translation even if it is an end-node.

This BTW has massive other implications/problems wrt to dealing with RAs, etc.
Are you aware of this?  I think it needs to be worded carefully to not imply
that the end-node would be a "forwarding device" to not run into these problems.

Generally, as an implementor, I always think it's bad to find requirement-levels
language in a "Terminology" section.  It usually means that the mandatory
functionality explanation is either duplicated or missing in a more appropriate
section.

I'd suggest a line break here in case it's to stay.

>                                                   In the case where the
>            access network does not allow for a dedicated IPv6 prefix for
>            translation, a NAT44 SHOULD be used between the router
>            function and the stateless translator function.  The CLAT as
>            a common home router or 3G router is expected to perform

or 4G? or generally "The CLAT as a router is ..."?

>            gateway functions such as DHCP server and DNS proxy for local
>            clients.  The CLAT does not comply with the sentence "Both
>            IPv4-translatable IPv6 addresses and IPv4-converted IPv6
>            addresses SHOULD use the same prefix." that is described on
>            Section 3.3 in [RFC6052] due to using different IPv6 prefixes
>            for CLAT-side and PLAT-side IPv4 addresses.
> 
> 
> 5.  Motivation and Uniqueness of 464XLAT
>
>    1.  Minimal IPv4 resource requirements, maximum IPv4 efficiency
>        through statistical multiplexing

[append] . [/append]

>
>    2.  No new protocols required, quick deployment

[append] . [/append]

>
>    3.  IPv6-only networks are simpler and therefore less expensive to
>        operate

[append] . [/append]

> 
> 
> 6.  Network Architecture
>
>    464XLAT architecture is shown in the following figure.

There is no figure following.  Maybe?

"Examples of 464XLAT architectures are show in the figures in the the following
sections."

which would also not limit the use cases to the given examples.

> 
> 
> 
> 
> 
> Mawatari, et al.        Expires February 8, 2013                [Page 4]
> 
> Internet-Draft                   464XLAT                     August 2012
> 
> 
> 6.1.  Wireline Network Architecture

Does it really matter whether this is Wireline, WiMax, Wifi, or carrier
pidgeons?

>
>    The private IPv4 host on this diagram can reach global IPv4 hosts via
>    translation on both CLAT and PLAT.  On the other hand, the IPv6 host
>    can reach other IPv6 hosts on the Internet directly without
>    translation.  This means that the CPE can not only have the function

I'd name the CLAT int he figure CPE/CLAT maybe?

>    of CLAT but also the function of IPv6 native router for IPv6 native

... of [insert] a [/insert] CLAT ... of [insert] an [/insert] IPv6 native router
for [swap?] native IPv6 [/swap?] traffic.

>    traffic.
> 
>
>                                   ----
>                                  | v6 |
>                                   ----
>                                     |
>     ----      |                 .---+---.                    .------.
>    | v6 |-----+                /         \                  /        \
>     ----      |    ------     /   IPv6    \     ------     /   IPv4   \
>               +---| CLAT |---+  Internet   +---| PLAT |---+  Internet  |
>     -------   |    ------     \           /     ------     \           /
>    |v4p/v6 |--+                `---------'                  `----+----'
>     -------   |                                                  |
>     -----     |                                                -----
>    | v4p |----+                                               | v4g |
>     -----     |                                                -----
>
>           <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->
>

Not sure the "IPv6 Internet" needs to be the "Internet" but can also just be
an IPv6 "network".

>
>      v6  : Global IPv6
>      v4p : Private IPv4
>      v4g : Global IPv4
>
>                     Figure 1: Wireline Network Topology
> 
> 6.2.  Wireless 3GPP Network Architecture
>
>    The CLAT function on the UE provides an [RFC1918] address and IPv4

Spell out UE on first use:  User Equipment (UE) ...

>    default route.  The applications on the UE can use the private IPv4
>    address for reaching global IPv4 hosts via translation on both CLAT
>    and PLAT.  On the other hand, reaching IPv6 hosts (including host
>    presented via DNS64 [RFC6147]) does not require the CLAT function on
>    the UE.

...

And a couple of other use cases missing here, not specific to 3GPP, etc.
As mentioned earlier, I am happy to ignore and update once implementations
exist.

> 
> 7.  Applicability
> 
> 7.1.  Wireline Network Applicability
>
>    When an ISP has IPv6 464XLAT, the ISP can provide outgoing IPv4
>    service to end users across an IPv6 access network.  The result is

The beginning of that first sentence needs rew-wording.  What does
"has IPv6 464XLAT" mean?  Do you mean "Providing a PLAT device, an ISP
can offer outgoing ..."?

>    that edge network growth is no longer tightly coupled to the
>    availability of scarce IPv4 addresses.
>
>    If the IXP or another provider operates the PLAT, the edge ISP is

"the IXP"?  Do you mean "ISP" or do you mean "an IXP" in which case it
needs to be spelt out as "IXP" is not the 'RFC Editor Abbreviations List'.

>    only required to deploy an IPv6 access network.  All ISPs do not need
>    IPv4 access networks.  They can migrate their access network to a
>    simple and highly scalable IPv6-only environment.
>
>    Incidentally, the effectiveness of 464XLAT was confirmed in the WIDE
>    camp Spring 2012.  The result is described in
> 
> 
> 
> Mawatari, et al.        Expires February 8, 2013                [Page 6]
> 
> Internet-Draft                   464XLAT                     August 2012
> 
>
>    [I-D.hazeyama-widecamp-ipv6-only-experience].
> 
> 7.2.  Wireless 3GPP Network Applicability
>
>    The vast majority of mobile 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 Packet Data
>    Protocol (PDP) attachments to access IPv4 and IPv6 network
>    destinations [RFC6459].  Since there are 2 PDPs required to support 2

s/2/two/g

>    address families, this is double the number of PDPs required to
>    support the status quo of 1 address family, which is IPv4.

s/1/one/

>
>    464XLAT in combination with stateful translation [RFC6146] and DNS64
>    [RFC6147] allows 85% of the Android applications to continue to work

Not sure I like "85% of the Android applications" in an RFC for a lot of
reasons: a) product name, b) number to be outdated the moment published,
c) number certainly not applicable anymore in a few months/years.

Either needs "at the time of publishing" or something or should be reworded
to be more general "allows a majority of applications" or something.  Remeber
that also others are affected including a desktop with a 3G dongle (if these
things work the same).

>    with single translation or native IPv6 access.  For the remaining 15%
>    of applications that require IPv4 connectivity, the CLAT function on
>    the UE provides a private IPv4 address and IPv4 default-route on the
>    host for the applications to reference and bind to.

Once again this is a current implementation specific detail I will ignore.
On a UE you are good w/o a default route.

s/default-route/default route/

>  Connections
>    sourced from the IPv4 interface are immediately routed to the CLAT
>    function and passed to the IPv6-only mobile network, destine to the

Hmm 'destine (to)' gives me a hard time.  'destined for'?

>    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].
>
>    464XLAT works with today's existing systems as much as possible.
>    464XLAT is compatible with existing network based deep packet
>    inspection solutions like 3GPP standardized Policy and Charging
>    Control (PCC) [TS.23203].
> 
> 
> 8.  Implementation Considerations
> 
> 8.1.  IPv6 Address Format
>
>    IPv6 address format in 464XLAT is defined in Section 2.2 of

[prepend] The [/prepend]

>    [RFC6052].
> 
> 8.2.  IPv4/IPv6 Address Translation Chart
> 
> 8.2.1.  Case of enabling only stateless XLATE on CLAT
>
>    This case should be used when a prefix delegation mechanism such as
>    DHCPv6-PD [RFC3633] is available to assign a dedicated translation
>    prefix to the CLAT.
> 
> 
> 
> 
> 
> 
> 
> Mawatari, et al.        Expires February 8, 2013                [Page 7]
> 
> Internet-Draft                   464XLAT                     August 2012

In general I found it confusing to have the source address before the
destination address in the direction of "travel" in all the following
figures.

>
>                                            Source IPv4 address
>                                           +----------------------------+
>                                           | Global IPv4 address        |
>                                           | assigned to IPv4 pool@PLAT |

This could be spelt as "IPv4 PLAT pool" as well?

>                                +--------+ +----------------------------+
>                                |  IPv4  |  Destination IPv4 address
>                                | server | +----------------------------+
>                                +--------+ | Global IPv4 address        |
>                                    ^      | assigned to IPv4 server    |
>                                    |      +----------------------------+
>                                +--------+
>                                |  PLAT  | Stateful XLATE(IPv4:IPv6=1:n)

I feel the 1:n is confusing.  First I feel it's IPv6:IPv4.  Then I am not sure
why it's n:1 but really n:m with m>=1, right?  As a lot of sources can be
mapped to one or more IPv4 (pool) addresses?  Given the question came up
on the list maybe a few words might help here as well?

>                                +--------+
>                                    ^
>                                    |
>          Source IPv6 address  (IPv6 cloud)
>         +--------------------------------------------------------------+
>         | IPv4-Embedded IPv6 address                                   |
>         | defined in Section 2.2 of RFC6052                            |
>         +--------------------------------------------------------------+
>          Destination IPv6 address
>         +--------------------------------------------------------------+
>         | IPv4-Embedded IPv6 address                                   |
>         | defined in Section 2.2 of RFC6052                            |
>         +--------------------------------------------------------------+
>                               (IPv6 cloud)
>                                    ^
>                                    |
>                                +--------+
>                                |        | In the case CLAT has a
>                                |        | dedicated IPv6 prefix for
>                                |  CLAT  | translation, the CLAT can
>                                |        | perform with only Stateless
>                                |        | XLATE (IPv4:IPv6=1:1).

So here it is addresses for a flow.  Ok, let me go back.  Kind of the problem
reading from bottom up;-)

>                                +--------+
>                                    ^       Source IPv4 address
>                                    |      +----------------------------+
>                                +--------+ | Private IPv4 address       |
>                                |  IPv4  | | assigned to IPv4 client    |
>                                | client | +----------------------------+
>                                +--------+  Destination IPv4 address
>                                           +----------------------------+
>                                           | Global IPv4 address        |
>                                           | assigned to IPv4 server    |
>                                           +----------------------------+
>
>                Case of enabling only stateless XLATE on CLAT
> 
> 
> 
> 
> Mawatari, et al.        Expires February 8, 2013                [Page 8]
> 
> Internet-Draft                   464XLAT                     August 2012
> 
> 
> 8.2.2.  Case of enabling NAT44 and stateless XLATE on CLAT
>

...

> Internet-Draft                   464XLAT                     August 2012
> 
>
>                                            Source IPv4 address
>                                           +----------------------------+
>                                           | Global IPv4 address        |
>                                           | assigned to IPv4 pool@PLAT |

This could be spelt as "IPv4 PLAT pool" as well?

>                                +--------+ +----------------------------+
>                                |  IPv4  |  Destination IPv4 address
>                                | server | +----------------------------+
>                                +--------+ | Global IPv4 address        |
>                                    ^      | assigned to IPv4 server    |
>                                    |      +----------------------------+
>                                +--------+
>                                |  PLAT  | Stateful XLATE(IPv4:IPv6=1:n)

Once again, as in previous example, unlcear.

>                                +--------+
>                                    ^
>                                    |
>          Source IPv6 address  (IPv6 cloud)
>         +--------------------------------------------------------------+
>         | IPv4-Embedded IPv6 address                                   |
>         | defined in Section 2.2 of RFC6052                            |
>         +--------------------------------------------------------------+
>          Destination IPv6 address
>         +--------------------------------------------------------------+
>         | IPv4-Embedded IPv6 address                                   |
>         | defined in Section 2.2 of RFC6052                            |
>         +--------------------------------------------------------------+
>                               (IPv6 cloud)
>                                    ^
>                                    |
>                                +--------+
>                                |        | In the case CLAT does not have

[insert] the [/insert] CLAT (I know space is tight) so feel free to ignore.

>                                |        | a dedicated IPv6 prefix for
>                                |  CLAT  | translation, the CLAT can
>                                |        | perform with NAT44 and
>                                |        | Stateless XLATE
>                                |        | (IPv4:IPv6=1:1).
>                                +--------+
>                                    ^       Source IPv4 address
>                                    |      +----------------------------+
>                                +--------+ | Private IPv4 address       |
>                                |  IPv4  | | assigned to IPv4 client    |
>                                | client | +----------------------------+
>                                +--------+  Destination IPv4 address
>                                           +----------------------------+
>                                           | Global IPv4 address        |
>                                           | assigned to IPv4 server    |
>                                           +----------------------------+
>
>             Case of enabling NAT44 and stateless XLATE on CLAT
> 
> 
> 
> Mawatari, et al.        Expires February 8, 2013               [Page 10]
> 
> Internet-Draft                   464XLAT                     August 2012
> 
> 
> 8.3.  IPv6 Prefix Handling
> 
> 8.3.1.  Case of enabling only stateless XLATE on CLAT
>
>    From the delegated DHCPv6 [RFC3633] prefix, a /64 is dedicated to
>    source and receive IPv6 packets associated with the stateless
>    translation [RFC6145].
>
>    The CLAT MAY discover the Pref64::/n of the PLAT via some method such
>    as DHCPv6 option, TR-069, DNS APL RR [RFC3123] or
>    [I-D.ietf-behave-nat64-discovery-heuristic].
> 
> 8.3.2.  Case of enabling NAT44 and stateless XLATE on CLAT
>
>    In the case that DHCPv6-PD [RFC3633] is not available, the CLAT does

s/does/may/  The CLAT could still know it through out of band configuration
mechanisms.  Or rather just remove the entire sentence.

>    not have dedicated IPv6 prefix for translation.  If the CLAT does not
>    have a dedicated IPv6 prefix for translation, the CLAT can perform
>    with NAT44 and stateless translation [RFC6145].
>
>    Incoming source IPv4 packets from the LAN of [RFC1918] addresses are

s/of [RFC1918 addresses//

There is no need the LAN would be restircted to RFC1918 addresses; in theory
ANY IPv4 address could work in this scenario, that is not conflicting with the
single "external" NAT44 address of the CLAT.  Assume that I do have a valid
v4 prefix and I am switching to a backup over LTE using this technology, why
would I not be able to continue to use my prefix internally with this CLAT?

>    NAT44 to the CLAT IPv4 host address.  Then, the CLAT will do a
>    stateless translation [RFC6145] so that the IPv4 packets from the
>    CLAT IPv4 host address are translated to the CLAT WAN IPv6 address as
>    described in [RFC6052].
>
>    Its subnet prefix is made of the delegated prefix, completed if
>    needed to a /64 by a subnet ID = 0.  Its interface ID is the 464XLAT
>    interface ID (Section 10).
>
>    The CLAT MAY discover the Pref64::/n of the PLAT via some method such
>    as TR-069, DNS APL RR [RFC3123] or
>    [I-D.ietf-behave-nat64-discovery-heuristic].
>

This leaves one question - which NAT44 address is the CLAT to use?  It can
be any really not comflictting with the PLAT pool.  How does the CLAT learn
that v4 address?  Should there be a single IPv4 address specified for the
NAT44 case?

...

> 8.5.  DNS Proxy Implementation
>
>    The CLAT SHOULD implement a DNS proxy as defined in [RFC5625].  The
>    case of an IPv4-only node behind CLAT querying an IPv4 DNS server is

... behind [insert] the [/insert] CLAT ...

>    undesirable since it requires both stateful and stateless translation
>    for each DNS lookup.  The CLAT SHOULD set itself as the DNS server
>    via DHCP or other means and proxy DNS queries for IPv4 and IPv6
>    clients.  Using the CLAT enabled home router or UE as a DNS proxy is
>    a normal consume gateway function and simplifies the traffic flow so

consume[append] r [/append]

>    that only IPv6 native queries are made across the access network.
>    The CLAT SHOULD allow for a client to query any DNS server of its
>    choice and bypass the proxy.
> 
> 8.6.  CLAT in a Gateway
>
>    The CLAT is a stateless translation feature which can be implemented
>    in a common home router or mobile phone that has a mobile router

Careful with the term "mobile router".  Maybe just "forwarding" or if it
is a 3GPPP term qualify it.

>    feature.  The router with CLAT function SHOULD provide common router
>    services such as DHCP of [RFC1918] addresses, DHCPv6, and DNS
>    service.  The router SHOULD set itself as the DNS server advertised
>    via DHCP or other means to the clients so that it may implement the
>    DNS proxy function to avoid double translation of DNS request.

... of DNS request [add] s [/add] .

Feels a bit repetitive given 8.5.

> 
> 8.7.  CLAT to CLAT communications
>
>    While CLAT to CLAT IPv4 communication may work when the client IPv4
>    subnets do not overlap, this traffic flow is out of scope. 464XLAT is
> 
> 
> 
> Mawatari, et al.        Expires February 8, 2013               [Page 12]
> 
> Internet-Draft                   464XLAT                     August 2012
> 
>
>    a hub and spoke architecture focused on enabling IPv4-only services
>    over IPv6-only access networks.
>

s/access//   Here it's actually easily possible to do so.

> 
> 9.  Deployment Considerations

This feels like it shoud be called "Traffic Engineering" or have a subsection
titled like that.

>
>    Even if the Internet access provider for consumers is different from

The entire "access provider" once again reads strangely too specific to me
but so be it for this version.

>    the PLAT provider (e.g. another internet access provider), it can
>    implement traffic engineering independently from the PLAT provider.
>    Detailed reasons are below:
>
>    1.  The Internet access provider for consumers can figure out IPv4

s/consumers/end users/ maybe to make it more clear?  Even the access provider
is a consumer of his upstream's resources;-)

>        destination address from translated IPv6 packet header, so it can
>        implement traffic engineering based on IPv4 destination address
>        (e.g. traffic monitoring for each IPv4 destination address,
>        packet filtering for each IPv4 destination address, etc.).  The
>        tunneling methods do not have such a advantage, without any deep

.. such a [append] n [/append] advantage ...

>        packet inspection for processing the inner IPv4 packet of the
>        tunnel packet.
>
>    2.  If the Internet access provider for consumers can assign IPv6

... assign [insert] an [/insert] IPv6 ...

>        prefix greater than /64 for each subscriber, this 464XLAT

s/for/to/

>        architecture can separate IPv6 prefix for native IPv6 packets and

s/prefix/prefixes/

>        XLAT prefix for IPv4/IPv6 translation packets.  Accordingly, it

... [add] the [/add] XLAT prefix ...

>        can identify the type of packets ("native IPv6 packets" and
>        "IPv4/IPv6 translation packets"), and implement traffic
>        engineering based on IPv6 prefix.

... on [insert] the [/insert] IPv6 ...

>
>    This 464XLAT architecture has two capabilities.  One is a IPv4 ->
>    IPv6 -> IPv4 translation for sharing global IPv4 addresses, another,
>    if combined with BIH [RFC6535], is a IPv4 -> IPv6 translation for
>    reaching IPv6-only servers from IPv4-only clients that can not
>    support IPv6.  IPv4-only clients must be support through the long
>    period of global transition to IPv6.

This does not match this section really.  It feels like the abstract
or introduction is repeated.

> 
> 
> 10.  Security Considerations
>
>    To implement a PLAT, see security considerations presented in Section
>    5 of [RFC6146].
>
>    To implement a CLAT, see security considerations presented in Section
>    7 of [RFC6145].  The CLAT MAY comply with [RFC6092].
> 
> 
> 11.  IANA Considerations
>
>    IANA is requested to reserve a Modified EUI-64 identifier for 464XLAT
> 
> 
> 
> Mawatari, et al.        Expires February 8, 2013               [Page 13]
> 
> Internet-Draft                   464XLAT                     August 2012
> 
>
>    according to section 2.2.2 of [RFC5342].  Its suggested value is 02-
>    00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF or 02-00-5E-10-00-00-
>    00-00 to 02-00-5E-EF-FF-FF-FF-FF, depending on whether it should be
>    taken in reserved or available values.

I could have missed something but where was this mentioned anywhere in the
text above, and what is it good for?  I see it was suggested by Remi given
the Acknowledgements but the draft simply nowhere describes or requires it.
Sorry, something is wrong here.

...

> Internet-Draft                   464XLAT                     August 2012
> 
> 
> Appendix A.  Examples of IPv4/IPv6 Address Translation
>
>    The following are examples of IPv4/IPv6 Address Translation on the
>    464XLAT architecture.
>
>    Example 1.  (Case of enabling only stateless XLATE on CLAT)
>
>    In the case that IPv6 prefix greater than /64 is assigned to end

... that [insert] an [/insert] IPv6 ...
... to [insert] an [/insert] end ...

>    users by such as DHCPv6-PD [RFC3633], only the function of Stateless
>    XLATE should be enabled on CLAT.  Because the CLAT can use dedicated

... only the Stateless XLATE functionality should be ... maybe?

... on [insert] the [/insert] CLAT. ...

>    a /64 from the assigned IPv6 prefix for Stateless XLATE.

[swap] dedicated / a [/swap]   (... can use a dedicated /64 ...)

It seems to only be half a sentence.   Maybe:

In the case that an IPv6 prefix greater than /64 is addigned to an end user
by such as DHCPv6-PD [RFC3633], only the Stateless XLATE functionality should
be enabled on the CLAT as the CLAT can use a dedicated /64 from the assigned
IPv6 prefix.

...

> Internet-Draft                   464XLAT                     August 2012
>

Prefiously in the draft you have used 2 boxes for src/dst IP, I like the single
box better; maybe yout want to adjust the previous figures as well?

>
>       Host & configuration value
>    +------------------------------+
>    |           IPv4 server        |
>    |         [198.51.100.1]       |            IP packet header
>    +------------------------------+   +--------------------------------+
>                    ^                  | Source IP address              |
>                    |                  | [192.0.2.1]                    |
>                    |                  | Destination IP address         |
>                    |                  | [198.51.100.1]                 |
>    +------------------------------+   +--------------------------------+
>    |              PLAT            |                   ^
>    | IPv4 pool address            |                   |
>    | [192.0.2.1 - 192.0.2.100]    |                   |
>    | PLAT-side XLATE IPv6 prefix  |                   |
>    | [2001:db8:1234::/96]         |                   |
>    +------------------------------+   +--------------------------------+
>                    ^                  | Source IP address              |
>                    |                  | [2001:db8:aaaa::192.168.1.2]   |
>                    |                  | Destination IP address         |
>                    |                  | [2001:db8:1234::198.51.100.1]  |
>    +------------------------------+   +--------------------------------+
>    |              CLAT            |                   ^
>    | PLAT-side XLATE IPv6 prefix  |                   |
>    | [2001:db8:1234::/96]         |                   |
>    | CLAT-side XLATE IPv6 prefix  |                   |
>    | [2001:db8:aaaa::/96]         |                   |
>    +------------------------------+   +--------------------------------+
>                    ^                  | Source IP address              |
>                    |                  | [192.168.1.2]                  |
>                    |                  | Destination IP address         |
>                    |                  | [198.51.100.1]                 |
>    +------------------------------+   +--------------------------------+
>    |          IPv4 client         |
>    |        [192.168.1.2/24]      |
>    +------------------------------+
>    Delegated IPv6 prefix for client: 2001:db8:aaaa::/56
> 
> 
> 
> 
>
>    Example 2.  (Case of enabling NAT44 and stateless XLATE on CLAT)
>
>    In the case that IPv6 prefix /64 is assigned to end users, the

In case only a /64 IPv6 prefix is ....  maybe?

>    function of NAT44 and Stateless XLATE should be enabled on CLAT.
>    Because the CLAT does not have dedicated IPv6 prefix for translation.

Again only half a sentence.  Rewrite the entire thing as well?

> 
> 
> 
> 
> 
> Mawatari, et al.        Expires February 8, 2013               [Page 17]
> 
> Internet-Draft                   464XLAT                     August 2012
> 
>
>       Host & configuration value
>    +-------------------------------+
>    |           IPv4 server         |
>    |         [198.51.100.1]        |            IP packet header
>    +-------------------------------+   +-------------------------------+
>                    ^                   | Source IP address             |
>                    |                   | [192.0.2.1]                   |
>                    |                   | Destination IP address        |
>                    |                   | [198.51.100.1]                |
>    +-------------------------------+   +-------------------------------+
>    |              PLAT             |                  ^
>    | IPv4 pool address             |                  |
>    | [192.0.2.1 - 192.0.2.100]     |                  |
>    | PLAT-side XLATE IPv6 prefix   |                  |
>    | [2001:db8:1234::/96]          |                  |
>    +-------------------------------+   +-------------------------------+
>                    ^                   | Source IP address             |
>                    |                   | [2001:db8:aaaa:200:5e10:0:0]  |

This is not a valid IPv6 source address.  Also see question below on the
local part.

>                    |                   | Destination IP address        |
>                    |                   | [2001:db8:1234::198.51.100.1] |
>    +-------------------------------+   +-------------------------------+
>    | CLAT Stateless XLATE function |                  ^
>    | - - - - - - - - - - - - - - - |                  |
>    | PLAT-side XLATE IPv6 prefix   |                  |
>    | [2001:db8:1234::/96]          |                  |
>    | CLAT-side XLATE IPv6 prefix   |                  |
>    | [2001:db8:aaaa::/64]          |                  |
>    | CLAT-side XLATE IPv6 EUI-64 ID|                  |
>    | [02-00-5E-10-00-00-00-00]     |                  |

Here we go; now that's not described in the draft above, sorry.  Not sure
why it needs to be special?  I guess the email archives would tell me, but
really the draft should.

Also, given I have no idea, I almost assume that a 00-00-00-00 might not
be what I'd expect in ths example?

>    + - - - - - - - - - - - - - - - +   +-------------------------------+
>    |               ^               |   | Source IP address             |
>    |               |               |   | [10.255.255.1]                |
>    |               |               |   | Destination IP address        |
>    |               |               |   | [198.51.100.1]                |
>    + - - - - - - - - - - - - - - - +   +-------------------------------+
>    | CLAT NAT44 function           |                  ^
>    | - - - - - - - - - - - - - - - |                  |
>    | NAT44 NATed address           |                  |
>    | [10.255.255.1/32]             |                  |
>    +-------------------------------+   +-------------------------------+
>                    ^                   | Source IP address             |
>                    |                   | [192.168.1.2]                 |
>                    |                   | Destination IP address        |
>                    |                   | [198.51.100.1]                |
>    +-------------------------------+   +-------------------------------+
>    |          IPv4 client          |
>    |        [192.168.1.2/24]       |
>    +-------------------------------+

...

---

From: Tom Taylor <[email-masked]>
Date: Tue, 14 Aug 2012 10:18:54 -0400

...

>>    access service to IPv6-only edge networks without encapsulation.

It's against the rules to put references in the Abstract as you suggest. 
The original text is OK here.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 14 Aug 2012 21:30:43 +0000 (UTC)

On Tue, 14 Aug 2012, Tom Taylor wrote:

> It's against the rules to put references in the Abstract as you suggest. The 
> original text is OK here.

Indeed .. unless they are completly defined within the abstract, which
is not the case here and indeed the least I am worried about.

I am still trying to find the EUI stuff in the archives, which is a
PITA.  In case someone has the reference (or link) I'd be happy.

/bz

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Aug 2012 09:35:56 +0900

On Tue, Aug 14, 2012 at 7:34 PM, Bjoern A. Zeeb <
[email-masked]> wrote:

> I could have missed something but where was this mentioned anywhere in
> the text above, and what is it good for?  I see it was suggested by Remi
> given the Acknowledgements but the draft simply nowhere describes or
> requires it. Sorry, something is wrong here.
>

+1. It's not clear to me why we need a special interface ID at all.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 14 Aug 2012 17:43:49 -0700

> +1. It's not clear to me why we need a special interface ID at all.

Here is a link to the discussion

http://www.ietf.org/mail-archive/web/v6ops/current/msg12880.html

The Android code Lorenzo is reviewing at the moment includes this afaik

CB _______________________________________________

---

From: GangChen <[email-masked]>
Date: Wed, 15 Aug 2012 12:16:05 +0800

> on the list maybe a few words might help here as well?

1:n is just a symbol of "IP Address Sharing" I guess

> mechanisms.  Or rather just remove the entire sentence.

Is there any practice to delegate IPv6 prefix through out-band approach?

> would I not be able to continue to use my prefix internally with this CLAT?

I guess RFC1631 could answer your question. FWIW, ".... NAT44[RFC1631] ...."

> that v4 address?  Should there be a single IPv4 address specified for the

Which address to be used on NAT44 really doesn't matter imho so long as external
IPv4 address doesn't conflict with internal address on NAT44. Such IPv4 address
is only of meaning within CLAT. PLAT would treat incoming data as an
normal IPv6 package and do translation depending on BIB/STE

> This feels like it shoud be called "Traffic Engineering" or have a

(*) Indeed. My comments to section 9:

It may be worth to restructure section a bit. the paragraph 1/2/3
match title of "Traffic Engineering" .
the paragraph 4 match title of "Traffic Treatment Scenarios", which is
name of section 8.4

I feel two approaches can try

1# 9 Deployment Considerations
   9.1 Traffic Engineering
   ....
   9.2 Traffic Treatment Scenarios
   ....

or

2# shift last paragraph to section 8.4

BTW, I'm a little bit hard to decode the last raw in the table of section 8.4
Aligning with the statement of
   " This 464XLAT architecture has two capabilities.  One is a IPv4 ->
   IPv6 -> IPv4 translation for sharing global IPv4 addresses, another,
   if combined with BIH [RFC6535], is a IPv4 -> IPv6 translation for
   reaching IPv6-only servers from IPv4-only clients that can not
   support IPv6.  IPv4-only clients must be support through the long
   period of global transition to IPv6."

It should be

        +--------+-------------+-----------------------+-------------+
        |  IPv6  |    IPv4     | Statefull Translation |    CLAT     |
        +--------+-------------+-----------------------+-------------+

Did I miss something?

> or introduction is repeated.
I feel the texts match section 8.4. =>See above (*)
> Sorry, something is wrong here.

Modified EUI-64 ID is used only in the case of 8.2.2 as Cameron
pointed the discussion
http://www.ietf.org/mail-archive/web/v6ops/current/msg12880.html.
One point to add is CLAT would do ND-proxy[RFC4389] implementing the
v6 tethering, which is also mentioned at section 5.3 RFC6459 afaik.

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Aug 2012 12:04:22 +0200

Le 2012-08-14 à 23:30, Bjoern A. Zeeb a écrit :

>> It's against the rules to put references in the Abstract as you suggest. The original text is OK here.
> 

Isn't tools.ietf.org/html/rfc5342#section-2.2.2 what you are looking for?

RD

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 15 Aug 2012 12:34:02 +0000 (UTC)

On Wed, 15 Aug 2012, Rémi Després wrote:

Hi,

> Isn't tools.ietf.org/html/rfc5342#section-2.2.2 what you are looking for?

No, I am still trying to understand why the special EUI is in the draft
at all.

Given the other reference I went back and read the entire thread
starting April 16 all the way into May on the -02 version of the
draft.  CB asked for text that I have never seen in a reply, which
might have helped.

As it stands:

1) I need a better explanation why the special EUI range is needed?
    The mumbling on linux and tethering and nd proxy and whatnot
    did not give me any reason why it was needed.

2) If it is really needed, the draft will need the explanation from
    (1) and we'll need to discuss why we need our own range rather than
    the one 5342 already provides for v4.

So let's start with (1)?  The more detaied you (pl) can be and the
better your concrete example is the more it would help to clarify
this quickly.

/bz

---

From: Dan Drown <[email-masked]>
Date: Wed, 15 Aug 2012 10:28:59 -0500

>    did not give me any reason why it was needed.

Given the following constraints on a smartphone:

* A handset allocated a single /64 IPv6 subnet

* That subnet is used for: regular v6 traffic (from the handset),  
464xlat, and regular v6 traffic (from tethered clients)

* 464xlat needs its own dedicated IPv6 subnet or address

You have the following choices:

1. Allocate a subnet of size /96 to /120 from the /64 to do a  
one-to-one mapping of IPv4 addresses to IPv6 addresses

2. Allocate a single IPv6 address out of the /64 subnet, map it to a  
single IPv4 address, and use NAT44 to provide IPv4 access to tethered  
clients

The drawback of choice #1 is when you have IPv6 tethering clients, you  
can't realisticly proxy ND the entire subnet.  With this, IPv6  
tethered clients have a chance of choosing an address that won't reach  
them, and the lack of proxy ND won't tell them of the conflict.

With the choice of #2, an IPv6 address for use with 464xlat must be  
selected.  An assigned interface id from a reserved EUI-64 range makes  
it less likely to conflict with a tethered client (since the /64  
subnet can be used with SLAAC-configured tethering clients).  Granted,  
the chance of conflict is already small and handled by DAD, but it's  
still good policy to avoid.

>    the one 5342 already provides for v4.

The IPv4 address range would be reasonable.  The EUI-64 would have the  
local bit set to 0, which means a chance of conflicting with tethered  
client's privacy address, but DAD should alert that host to select a  
new privacy address.

---

From: GangChen <[email-masked]>
Date: Wed, 15 Aug 2012 23:37:12 +0800

>     did not give me any reason why it was needed.

Trying to share my thought as an observer.

464xlat implementation adopts "/dev/tun" to steer incoming IPv4
packages to translation module. TUN simulates a network layer device
and it require a IPv6 address to be configured. When DHCP-PD is not
availed in some cases, v6 tethering would be performed through ND
proxy. If the IID of IPv6 address on TUN device is regular, the IPv6
address should be eliminated within LAN side in order to avoid
potential IID confliction. That increases implementation complexity in
some sense.
Therefore a Modified EUI-64 identifier is proposed to be IID on the
tun device. The reserved identifiers could prevent the occurrence of
IID confliction so as to ND-proxy doesn't need to exclude any
particular IPv6 address. Besides, ISPs can also recognize
doubly-translated packets by means of this particular IID.

The discussion before also tried to figure out "TAP" approach as an
alternative way. But it's realized it can't be achieved since TAP
can't handle point to point frame if I understood correctly.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 15 Aug 2012 20:52:43 +0000 (UTC)

On Wed, 15 Aug 2012, Dan Drown wrote:

> * That subnet is used for: regular v6 traffic (from the handset), 464xlat, 
> and regular v6 traffic (from tethered clients)
>
> 1. Allocate a subnet of size /96 to /120 from the /64 to do a one-to-one 
> mapping of IPv4 addresses to IPv6 addresses
>
> 2. Allocate a single IPv6 address out of the /64 subnet, map it to a single 
> IPv4 address, and use NAT44 to provide IPv4 access to tethered clients
>
> The drawback of choice #1 is when you have IPv6 tethering clients, you can't 
> realisticly proxy ND the entire subnet.  With this, IPv6 tethered clients 
> have a chance of choosing an address that won't reach them, and the lack of 
> proxy ND won't tell them of the conflict.
>
>
> With the choice of #2, an IPv6 address for use with 464xlat must be selected. 
> An assigned interface id from a reserved EUI-64 range makes it less likely to 
> conflict with a tethered client (since the /64 subnet can be used with 
> SLAAC-configured tethering clients).  Granted, the chance of conflict is 
> already small and handled by DAD, but it's still good policy to avoid.

Hmm `man U/L bit`?  `man RFC4193`?

I'd keep SLAAC out of the argument here; these shhuld really be
globally unique addresses and use the other 63 (62) bit of the IID.

So what's the real problem?  That the locally administered address(es)
clash with the single IPv6 address used for translation in the NAT44
case or the /96 address block used for 1:1 translation or that
these might clash with the addresses used with privacy extensions on?
They'd all live in the same 63 (62) bit space already anyway.

I don't see any point in making that XLAT464 related ones any special;
you already have to deal with all of this in the tethered environment
or just on the local host, why to complicate matters by adding another
player to the game?

I clearly think (2) of my original request is not necessary.  The IANA
section should be emptied.  There is no reason for another special
clas of EUI mangling.

/bz

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Aug 2012 09:54:36 +0900

On Thu, Aug 16, 2012 at 12:28 AM, Dan Drown <[email-masked]> wrote:

> can't realisticly proxy ND the entire subnet.  With this, IPv6 tethered
> clients have a chance of choosing an address that won't reach them, and the
> lack of proxy ND won't tell them of the conflict.
>
>
> selected.  An assigned interface id from a reserved EUI-64 range makes it
> less likely to conflict with a tethered client (since the /64 subnet can be
> used with SLAAC-configured tethering clients).  Granted, the chance of
> conflict is already small and handled by DAD, but it's still good policy to
> avoid.

Why not just do #2 and choose, as the interface ID, the interface ID of the
interface that is providing tethering? Does that make it hard to implement?

Also - if you're the tethering device, you are by definition the subnet
router. Can you pick the interface ID of :: ?

---

From: MAWATARI Masataka <[email-masked]>
Date: Thu, 16 Aug 2012 13:49:21 +0900

Dear all,

We authors really appreciate for discussion about the case of
assigning /64 to end in 464XLAT.

We think that we have to clarify that this is implementors'
choice in the document.  Implementor of CLAT can choose from using
IANA's EUI-64 ID or using a single IPv6 address or Proxy ND, etc.

That point is not the key proposal in 464XLAT as a architecture
using combination of RFC 6145 and RFC 6146.  It depends on
implementor of CLAT and it is independent from interoperability
between PLAT and CLAT.

Finally, 464XLAT can defer to implementor of CLAT on that point.

Kind Regards,
Masataka MAWATARI

* On Thu, 16 Aug 2012 09:54:36 +0900

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Aug 2012 15:36:22 +0900

> IANA's EUI-64 ID or using a single IPv6 address or Proxy ND, etc.

Well, but the implementor cannot choose to use a IANA-reserved EUI-64
unless IANA reserves an EUI-64 value for 464xlat. And IANA won't reserve an
EUI-64 value for 464xlat if this document not contain a request to IANA to
reserve it. This is why we are discussing whether to request a reserved
EUI-64 or not.

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Aug 2012 09:27:39 +0200

2012-08-16 à 08:36, Lorenzo Colitti :

> On Thu, Aug 16, 2012 at 1:49 PM, MAWATARI Masataka <[email-masked]> wrote:
> Well, but the implementor cannot choose to use a IANA-reserved EUI-64 unless IANA reserves an EUI-64 value for 464xlat. And IANA won't reserve an EUI-64 value for 464xlat if this document not contain a request to IANA to reserve it. This is why we are discussing whether to request a reserved EUI-64 or not.

Right.

1. Reserving an IPv6 address for NAT44-enabled CLATs ensures that no conflict _can exist_ between this address and that of an IPv6 host that has a local-scope interface IDs chosen before 464XLAT activation (design orthogonality).

2. Once this reservation is made, always using it is simpler than permitting implementation variants.

3. The draft can be clarified concerning this address, at least by correcting its section-number typo.
Suggestions:
- In 8.2.2,
 . s/mapped to a single IPv6 address/mapped to the single IPv6 address specified in section 8.3.2/  
 . In the source address of the figure, s/IPv4-Embedded IPv6 address defined in Section 2.2 of RFC6052/IPv6 address specified in section 8.3.2/
- In section 8.3.2, 
 . s/the CLAT WAN IPv6 address as described in [RFC6052]/the CLAT WAN IPv6 address specified as follows/
 . s/(Section 10)/(Section 11)/ (typo)
- In section 11,
 . s/IANA is requested/For the IPv6 Interface ID of NAT44-enabled-CLATs  (Section 8.3.2), IANA is requested/

Hope it clarifies.

RD

---

From: Tore Anderson <[email-masked]>
Date: Thu, 16 Aug 2012 11:42:12 +0200

* Lorenzo Colitti

> On Thu, Aug 16, 2012 at 12:28 AM, Dan Drown <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     single IPv4 address, and use NAT44 to provide IPv4 access to
>     tethered clients
> 
>     selected.  An assigned interface id from a reserved EUI-64 range
>     makes it less likely to conflict with a tethered client (since the
>     /64 subnet can be used with SLAAC-configured tethering clients).
>      Granted, the chance of conflict is already small and handled by
>     DAD, but it's still good policy to avoid.
> 
> 
> Why not just do #2 and choose, as the interface ID, the interface ID of
> the interface that is providing tethering? Does that make it hard to
> implement?
> 

A tethered Linux host with IPv6 forwarding enabled (could be done by
virtualisation software, for example) will also claim :: as an interface
ID, so that would likely cause a conflict.

Authors: Section 8.3.2 says «Its interface ID is the 464XLAT interface
ID (Section 10)». Shouldn't this say Section 11 instead?

BR,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 16 Aug 2012 09:58:42 +0000 (UTC)

> A tethered Linux host with IPv6 forwarding enabled (could be done by

Can we please stop modeling things after a specific OS, there are too
many out there that are relevant enough.  I admit and love to have
runnign code but I also love to be independent in my choice on where
to do my implementation.

Hearing out of band that 3GPP actually makes this entire thing a lot
easier as the entire /64 gets routed to the UE and the address does
not need to live on the provider facing side (which it wouldn't need
to anyway given v6 porposed standards) this entire discussion is
really not needed.  The magic EUI is just overhead; it's possible but
it's overhead and unless someone convinces me that I'd save power, I
don't see any reason to go the entire IANA road to get it allocated or
reuse the one there for v4 mappings and bloat the draft.

-1, remove it, ship it, good.

/bz

---

From: Tore Anderson <[email-masked]>
Date: Thu, 16 Aug 2012 12:20:18 +0200

* Bjoern A. Zeeb

> runnign code but I also love to be independent in my choice on where

As I understand it, any node that implements RFC 2373 section 2.6.1 and
is also operating as a router must claim ::. The mention of Linux was
just meant as a real-world example.

There is certainly similar virtualisation software available for other
operating systems, that allows the user to set up virtual internal
networks and route between them and the physical ones. I don't know if
those other OSes implement the subnet-router anycast address, but if
they do, they will end up conflicting as well.

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Aug 2012 12:39:45 +0200

Hi, Bjoern,

1. As said earlier, "reserving an IPv6 address for NAT44-enabled CLATs ensures that no conflict _can exist_ between this address and that of an IPv6 host that has a local-scope interface IDs chosen before 464XLAT activation". This is key where CLATs cannot have exclusive /64s, distinct from those used for native IPv6. 

2. Could you detail what you mean by "the address does not need to live on the provider facing side (which it wouldn't need to anyway given v6 proposed standards)" in cases where complete /64s are routed to UEs. 
- Which address are you referring to?
- Aren't such /64s used for both CLATs and native IPv6? 

Thanks,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 16 Aug 2012 06:29:34 -0700

> to anyway given v6 porposed standards) this entire discussion is

That is correct that the provider side does not consume an address from the
/64 in 3gpp but may in other designs such as ftth, but i believe the
challenege is on tetherside conflicts for 3gpp networks.... PC's and
tablets that tether to a phone may have conflicting addresses.

CB

---

From: Dan Drown <[email-masked]>
Date: Thu, 16 Aug 2012 09:05:42 -0500

> interface that is providing tethering? Does that make it hard to implement?

That may work for some implementations, but not for android-clat.  The  
clat function needs its own address, and it cannot be any address that  
the handset considers local.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 17 Aug 2012 10:42:38 +0000 (UTC)

On Thu, 16 Aug 2012, Dan Drown wrote:

> That may work for some implementations, but not for android-clat.  The clat 
> function needs its own address, and it cannot be any address that the handset 
> considers local.

/me bites his tongue.

Seriously?  Out of curiosity, can you elaborate (feel free to do so unicast).

---

From: Dan Drown <[email-masked]>
Date: Fri, 17 Aug 2012 09:49:53 -0500

Quoting "Bjoern A. Zeeb" <[email-masked]>:
>> That may work for some implementations, but not for android-clat.   
>> The clat function needs its own address, and it cannot be any  
>> address that the handset considers local.
>
> /me bites his tongue.
>

Yes.  The implementation of clat for android is done in userspace  
(using a tun interface to pass traffic between the kernel and the  
userspace program), and needs its own address.  Otherwise native  
traffic from the handset to the plat prefix (apps that support DNS64's  
rewritten AAAA answers) can't be seperated from translated traffic  
from the clat.  Perhaps this is just an implementation detail that  
doesn't need to go into the standard, but it's unavoidable for me.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 17 Aug 2012 08:28:31 -0700

>>> That may work for some implementations, but not for android-clat.  The
clat function needs its own address, and it cannot be any address that the
handset considers local.
> Yes.  The implementation of clat for android is done in userspace (using
a tun interface to pass traffic between the kernel and the userspace
program), and needs its own address.  Otherwise native traffic from the
handset to the plat prefix (apps that support DNS64's rewritten AAAA
answers) can't be seperated from translated traffic from the clat.  Perhaps
this is just an implementation detail that doesn't need to go into the
standard, but it's unavoidable for me.

The benefit of running code (thanks Dan!) is that we can learn these
lessons early and publish the most fit solution.

That said, the IANA section is useful for some implementors and has no
known drawbacks. It is up to the implementor to decide the best method,
this I-D just provides the tools and options.

CB

---

From: Washam Fan <[email-masked]>
Date: Mon, 20 Aug 2012 13:47:00 +0800

Hi,

Sorry for the late response. I finally got a chance to review this
edition and had some confusions
1. in sec 8.3.2, it lacks of elaborating on how to differentiate
native IPv6 packet from translated IPv6 packet. is it where reserved
IANA Modified EUI-64 ID comes in?
2. BIH only mentioned in two places in the draft and not mentioned in
abstract. If we want to cover BIH, shouldn't we elaborate a bit on how
to combine BIH with 464xlate? Or is it too obvious to talk about that?
3. Are BIH exclusive with rfc6145? in other words, enabling both BIH
and rfc6145 on CLAT is OK?

Thanks,
washam

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Aug 2012 11:23:30 +0900

On Fri, Aug 17, 2012 at 11:49 PM, Dan Drown <[email-masked]> wrote:

> Quoting "Bjoern A. Zeeb" <[email-masked].**net<[email-masked]>
> >:
>
> Yes.  The implementation of clat for android is done in userspace (using a
> tun interface to pass traffic between the kernel and the userspace

Fair enough. But that doesn't require a special EUI-64 to be allocated,
right? All you need is an IPv6 address that can be defended against DAD.
Can we then just say "if the CLAT picks an IPv6 address to use on the LAN
side, then it must make sure to reply to DAD on that address"?

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 20 Aug 2012 20:21:45 -0700

Thanks for the review.

> IANA Modified EUI-64 ID comes in?

Example 2 should help make this clear
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#appendix-A

> to combine BIH with 464xlate? Or is it too obvious to talk about that?

We do not have real experience with BIH, so we choose to only mention
how it fits into the architecture for the future case of IPv4-only
client to IPv6-only server without going into too much detail.

> and rfc6145 on CLAT is OK?

It should be OK. The BIH functions and the CLAT RFC6145 functions
should happen independently.

CB

---

From: Washam Fan <[email-masked]>
Date: Tue, 21 Aug 2012 11:54:06 +0800

Hi Cameron,

Please see inline.

> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#appendix-A

Yes. 464xlat-07 addresses this concern a lot. But what if the address
2001:db8:aaaa:0:200:5e10:: present in the example 2 is used for native
IPv6 communication? Or any methods preventing such use should be
mentioned?

> client to IPv6-only server without going into too much detail.
If so, why just remove BIH to keep the memo concise.

Thanks,
washam

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 20 Aug 2012 21:21:26 -0700

Washam,

> IPv6 communication? Or any methods preventing such use should be

That scenarios is statistically unlikely enough for me, and with a
dedicate EUI-64 further unlikely for even the pessimist in the WG

> If so, why just remove BIH to keep the memo concise.

There was a fairly long conversation here, there are also others:

http://www.ietf.org/mail-archive/web/v6ops/current/msg12630.html

The conclusion was that the 464XLAT is more complete by making a
reference to BIH scenario.

CB

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Aug 2012 14:31:26 +0900

> right?  All you need is an IPv6 address that can be defended against

you certainly have convinced me of this point.  so consider this a wglc
'to be fixed' request.

randy

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Aug 2012 09:41:32 +0200

2012-08-21 04:23, Lorenzo Colitti :

> That may work for some implementations, but not for android-clat.  The clat function needs its own address, and it cannot be any address that the handset considers local.
> 
> /me bites his tongue.
> 
> Yes.  The implementation of clat for android is done in userspace (using a tun interface to pass traffic between the kernel and the userspace program), and needs its own address.  Otherwise native traffic from the handset to the plat prefix (apps that support DNS64's rewritten AAAA answers) can't be seperated from translated traffic from the clat.  Perhaps this is just an implementation detail that doesn't need to go into the standard, but it's unavoidable for me.
> 
> Fair enough. But that doesn't require a special EUI-64 to be allocated, right? All you need is an IPv6 address that can be defended against DAD. Can we then just say "if the CLAT picks an IPv6 address to use on the LAN side, then it must make sure to reply to DAD on that address"?

Sure, the CLAT node must indeed reply to DAD on the address it has on the LAN side (as usual).

But the point is that, if the interface ID used by the CLAT the WAN-side is one that a host may use on the LAN (according to RFC 4291), this ID must be excluded on the LAN side IN ADDITION to that of the LAN-side address.
This obligation is avoided if interface ID 02-00-5E-10-00-00-00-00 is reserved for CLAT addressing. (It belongs to a range that is precisely "available for allocation" in RFC 5342, and therefore to never be used by any host).  

Note that, with words proposed in www.ietf.org/mail-archive/web/v6ops/current/msg13856.html using this ID in NAT44-enabled cases is only a SHOULD. This permits implementations that don't use it if found preferable for some good reason. But, at least, it also permits implementations that takes advantage of this ID.
Your insistance to go backward on this issue is hard to understand.

Regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Aug 2012 16:55:57 +0900

On Tue, Aug 21, 2012 at 4:41 PM, Rémi Després <[email-masked]>wrote:

> But the point is that, if the interface ID used by the CLAT the WAN-side
> is one that a host may use on the LAN (according to RFC 4291), this ID must
> be excluded on the LAN side IN ADDITION to that of the LAN-side address.
>

Agreed. If the CLAT assigns itself an IPv6 address on the WAN site, it must
defend that address against DAD on the LAN interface.

> This obligation is avoided if interface ID 02-00-5E-10-00-00-00-00 is
> reserved for CLAT addressing. (It belongs to a range that is precisely "available
> for allocation" in RFC 5342, and therefore to never be used by any host).
>

That's one way to solve the problem: avoid duplicate addresses by making
CLAT use a range that is reserved only for CLAT. In essence, you're
avoiding duplicate addresses by forbidding them.

Another way to solve the problem is to use the standard IPv6 mechanism used
to avoid duplicate addresses, i.e., DAD.

Why can't we just say that the CLAT MUST perform DAD properly for all the
addresses that it uses, and just leave it at that? It seems excessive to
request a reserved range from IANA just for the purposes of avoiding
duplicate addresses, when DAD would do the job just fine.

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Aug 2012 10:07:49 +0200

Le 2012-08-21 à 09:55, Lorenzo Colitti a écrit :

> On Tue, Aug 21, 2012 at 4:41 PM, Rémi Després <[email-masked]> wrote:
> 
> Agreed. If the CLAT assigns itself an IPv6 address on the WAN site, it must defend that address against DAD on the LAN interface.
>  
> That's one way to solve the problem: avoid duplicate addresses by making CLAT use a range that is reserved only for CLAT. In essence, you're avoiding duplicate addresses by forbidding them.
> 
> Another way to solve the problem is to use the standard IPv6 mechanism used to avoid duplicate addresses, i.e., DAD.
> 
> Why can't we just say that the CLAT MUST perform DAD properly for all the addresses that it uses, and just leave it at that? It seems excessive to request a reserved range from IANA just for the purposes of avoiding duplicate addresses, when DAD would do the job just fine.

Note that it is only ONE allocated value (in a range "available for allocation"). 

I can't understand why consuming a value, among many that have been made available for that, would be a big issue, especially since doing so permits to simplify some implementations.
Have you some reason you can share for such a concern?

RD

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Aug 2012 17:17:36 +0900

> I can't understand why consuming a value, among many that have been
> made available for that, would be a big issue, especially since doing
> so permits to simplify some implementations.  Have you some reason you
> can share for such a concern?

because it is *not* *needed* and solves nothing.  use the existing
mechanism, dad.  and, if you are prudent, you will have to do so anyway,
iana special or not.

randy

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 21 Aug 2012 08:27:12 +0000 (UTC)

> addresses that it uses, and just leave it at that? It seems excessive to

There is not even a need to say that.  If you talk IPv6 you need to do
this and any IPv6 address configured for use by the CLAT or just for
plain v6 needs to do it. You would even need to do it for a special
EUI address.  End of story.

The real problem I see and from what I learnt is that people are
thinking too many global addresses on a single device once again;
there is no need for two global addresses, one on the outside (3GPP/DSL/
CABLE/you name it) and one on the wifi interface to my understanding
as long as the entire prefix is routed to the device, which it is in
the tethering case I have been told, which what this entire discussion
is about.  Correct me if I am wrong.

/bz

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Aug 2012 10:56:05 +0200

> mechanism, dad.  and, if you are prudent, you will have to do so anyway,

My question was, why would it be difficult to get IANA to register an interface ID, one which is in a range explicitly "available for allocation". AFAIK it isn't difficult (but open to hear what others have to say).

Solves nothing is the point of different understanding.
- DAD isn't a solution if 464XLAT is activated after hosts have been given their interface IDs. 
- Keeping functions independent has always been better than creating mutual constraints. (I suspect you agree on this.)

Having code against a particular manual misconfiguration of a host address (one that doesn't comply with RFC 4291) would AFAIK be excessive "prudence". No need for it.

RD

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Aug 2012 18:02:32 +0900

> My question was, why would it be difficult to get IANA to register an
> interface ID, one which is in a range explicitly "available for
> allocation". AFAIK it isn't difficult (but open to hear what others
> have to say).

while we are asking the iana for things which are not needed but are not
difficult, let's get some ports, a few ipv4 address blocks, and some
ipv6 space while we're at it.

this is ridiculous.

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Aug 2012 18:12:08 +0900

On Tue, Aug 21, 2012 at 5:07 PM, Rémi Després <[email-masked]>wrote:

> Agreed. If the CLAT assigns itself an IPv6 address on the WAN site, it
> must defend that address against DAD on the LAN interface.
>
>
> Another way to solve the problem is to use the standard IPv6 mechanism
> used to avoid duplicate addresses, i.e., DAD.
>
> Note that it is only ONE allocated value (in a range "available forallocation").
>
>
> I can't understand why consuming a value, among many that have been made
> available for that, would be a big issue, especially since doing so permits
> to simplify some implementations.
Not really. The issues that I see are:

a) It's not needed. If we make a request to IANA, others might ask the same
question. "Why are you asking IANA to reserve an interface ID when you can
just do DAD?"
b) Reserving an IID and not doing DAD will tempt implementations to assume
the IID unique, creating problems when (not if) it's not unique any more.
Think of two CLAT gateways on the same link, for example.
b) Reserving an IID will also tempt operators to assume that the IID never
changes, and use that information for support or billing purposes.
d) It doesn't really simplify implementations, since there are now two
modes (reserved IID and DAD).

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Aug 2012 11:15:13 +0200

> this is ridiculous.

At least, we agree that the proposal above (not mine) can be described as you say, 

RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Aug 2012 18:19:34 +0900

> is about.  Correct me if I am wrong.

That's not a problem with the specification, but with the implementation.
IMO:

- The draft should state that any addresses assigned to the clat must be
subject to duplicate address detection as usual.
- An implementation can use one address if it wants.
- Some implementations, like Dan's implementation of CLAT, use two.

There are plenty of addresses in the /64, and this is not a problem.

No?

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Aug 2012 11:56:12 +0200

> EUI address.  End of story.

For non EUI addresses (which would be the case without the CLAT interface ID), RFC 4862 says (section 5.4.5 "When Duplicate Address Detection Fails"):
"On the other hand, if the duplicate link-local address is not formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned, IP operation on the interface MAY be continued."
Consequences can be messy, while they are simply avoided with an exclusive CLAT interface ID.

> is about.  Correct me if I am wrong.

Note that the CLAT interface ID is NOT configured an any IPv6-link interface.

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Aug 2012 11:59:00 +0200

Le 2012-08-21 à 11:12, Lorenzo Colitti a écrit :

> 
> 
> On Tue, Aug 21, 2012 at 5:07 PM, Rémi Després <[email-masked]> wrote:
> 
> a) It's not needed. If we make a request to IANA, others might ask the same question. "Why are you asking IANA to reserve an interface ID when you can just do DAD?"

DAD, even played in unusual conditions, doesn't provide a complete a solution (see my answer to Bjoern).

> b) Reserving an IID and not doing DAD will tempt implementations to assume the IID unique, creating problems when (not if) it's not unique any more. Think of two CLAT gateways on the same link, for example.

Not unique interface ID any more? (Once registered a by IANA, it remains unique.)
With NAT44s in CLAT nodes, which is the assumption, the two nodes must have, I suppose, different IPv6 prefixes. I don't see any problem. 

> b) Reserving an IID will also tempt operators to assume that the IID never changes, and use that information for support or billing purposes.

Are you suggesting that the 464XLAT model should be completed by a suggestion to change the CLAT IPv6 address from time to time?
We are getting really far from the question at hand.

> d) It doesn't really simplify implementations, since there are now two modes (reserved IID and DAD).

1. Suggestion: take the CLAT IID, and forget the theoretical and operational problems that can occur if relying only on a patched DAD.

2. Is you point that you personally find it difficult to implement the allocated CLAT IID (that of example 2 in the appendix)? 
If not, your request to change the draft on this is AFAIK a request for a step backward.

To conclude at this stage: if a rough consensus would be declared in the WG that an allocated CLAT IID should be deleted from the draft because it is assumed to serve no purpose, it would in my understanding be a mistake. Reasons for this may not have been understood, but they have at least been documented. Each one remains responsible for what he writes.

RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Aug 2012 20:24:27 +0900

On Tue, Aug 21, 2012 at 6:59 PM, Rémi Després <[email-masked]>wrote:

> 2. Is you point that you personally find it difficult to implement the
> allocated CLAT IID (that of example 2 in the appendix)?
>

No (and I'm not the one doing the implementation). The reasons why I think
we should not request IANA to allocate an IID are:

1. Operational experience that while it's good to ensure things are unique
by decree, in practice that leads to things not being unique some of the
time (e.g., MAC addresses - they're supposed to be duplicates, but guess
what, they're not). Thus, I prefer methods that are dynamic.
2. It's better to avoid hard-coding things if you can.
3. I just don't see a compelling need for a unique IID. The translation
mechanism would work fine without it (assuming you do DAD, which these
nodes need to do anyway for other addresses such as their link-local
addresses). I don't see why we need to trouble IANA with a request for a
unique IID if we don't need one.

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Aug 2012 15:05:31 +0200

Le 2012-08-21 à 13:24, Lorenzo Colitti a écrit :

> On Tue, Aug 21, 2012 at 6:59 PM, Rémi Després <[email-masked]> wrote:
> No (and I'm not the one doing the implementation).

I take is as a confirmation that implementation is trivial once the CLAT IID is defined.

> The reasons why I think we should not request IANA to allocate an IID are:
> 
> 1. Operational experience that while it's good to ensure things are unique by decree, in practice that leads to things not being unique some of the time (e.g., MAC addresses - they're supposed to be duplicates, but guess what, they're not).

The good news is that implementations don't use the CLAT IID won't disturb those that do, and conversely. There is no interworking issue here.

To be constructive, I can agree to a MAY in place of the previously proposed SHOULD. This permits to use it, my recommendation, or not to use it, your recommendation.

> Thus, I prefer methods that are dynamic.

Sometimes yes, sometimes no (the more parameters, the more complex is product qualification).

> 3. I just don't see a compelling need for a unique IID. 

Seeing no compelling reason to impose it is not contradictory to permitting it.

> The translation mechanism would work fine without it (assuming you do DAD, which these nodes need to do anyway for other addresses such as their link-local addresses). I don't see why we need to trouble IANA with a request for a unique IID if we don't need one.

IANA isn't AFAIK a body to be troubled by doing its job of registering assigned numbers found useful in IETF.

I therefore hope we can agree to "The CLAT MAY use the reserved  IANA assigned EUI-64 ID of Section 11 ..." in section 8.3.2 would satisfy expressed concerns.

Regards,
RD

---

From: Ole Trøan <[email-masked]>
Date: Tue, 21 Aug 2012 15:26:36 +0200

> No (and I'm not the one doing the implementation). The reasons why I think we should not request IANA to allocate an IID are:
> 
> 1. Operational experience that while it's good to ensure things are unique by decree, in practice that leads to things not being unique some of the time (e.g., MAC addresses - they're supposed to be duplicates, but guess what, they're not). Thus, I prefer methods that are dynamic.
> 3. I just don't see a compelling need for a unique IID. The translation mechanism would work fine without it (assuming you do DAD, which these nodes need to do anyway for other addresses such as their link-local addresses). I don't see why we need to trouble IANA with a request for a unique IID if we don't need one.

+1. keep it simple. it isn't at all clear to me what value a reserved IID has. just putting two CLATs on the same link would result in a collision...

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Aug 2012 09:53:34 -0400

If you are determined to see an EUI registered, the best solution might
be to write another draft doing so and indicating how it could be used
in the 464xlat case and any other case you imagine.

On 21/08/2012 9:05 AM, Rémi Després wrote:
...

>
> The good news is that implementations don't use the CLAT IID won't
> disturb those that do, and conversely. There is no interworking issue
> here.
>
> To be constructive, I can agree to a MAY in place of the previously
> proposed SHOULD. This permits to use it, my recommendation, or not to
> use it, your recommendation.
>
>
...

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Aug 2012 17:45:59 +0200

> in the 464xlat case and any other case you imagine.

Keeping the draft with it makes more sense.
With a MAY, I don't see any valid objection that remains.
Remember that the draft was considered by authors ready for WGLC with this registered EUI.

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Aug 2012 18:23:41 +0200

Hi, Ole,

2012-08-21 15:26, Ole Trøan:

> +1. keep it simple.

> it isn't at all clear to me what value a reserved IID has.

Many explanations have been given, and can be read.

> just putting two CLATs on the same link would result in a collision...

Collision of what, where? A FUD entertaining statement should at least be supported with some technical explanation (IMHO). 

But here, the statement is simply false:
- Each CLAT having its exclusive /64, any address derived from it belongs only to this CLAT, and cannot collide
- Even without a CLAT assigned interface ID, two CLATs can use common interface IDs on the WAN side.

RD

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Aug 2012 05:03:44 +0900

> Many explanations have been given, and can be read.

and they did not stand up.

wg last call has started.  i dissent.  i hope there is no need to repeat
the discussion.

randy

---

From: james woodyatt <[email-masked]>
Date: Tue, 21 Aug 2012 13:52:32 -0700

On Aug 21, 2012, at 13:03 , Randy Bush <[email-masked]> wrote:
> 
> wg last call has started.  i dissent.

I've been quietly following this discussion, and I think it's time I stood up to say that I agree with Mr. Bush and those who say the request for IANA to reserve a modified EUI-64 is unnecessary and arguably counter-productive.  It should be removed before the draft is sent to the IESG for review.

For my own part, I don't see why avoiding DAD should be a worthwhile objective unless the concern is about the time it takes to perform DAD while the address is still in the TENTATIVE state, to which I reply *cough* RFC 4429 *cough*.  I am not sanguine about arguments that a Best Current Practice should recommend a work-around for an implementation issue in one particular platform that isn't generally required everywhere.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Aug 2012 09:27:53 +0900

On Wed, Aug 22, 2012 at 1:23 AM, Rémi Després <[email-masked]>wrote:

> Collision of what, where? A FUD entertaining statement should at least be
> supported with some technical explanation (IMHO).
>

Put one CLAT behind the other. The first CLAT gets a /64 from upstream and
passes it on to its downstream. The second CLAT gets the RA from the first
with the same /64. Both are on the same /64. They both pick the same IID
because that's what the draft tells them to do. Voila, the same IPv6
address is assigned to two hosts.

---

From: Washam Fan <[email-masked]>
Date: Wed, 22 Aug 2012 12:36:38 +0800

Hi Remi,

> - Each CLAT having its exclusive /64, any address derived from it belongs only to this CLAT, and cannot collide

What about the collision between the CLAT and the hosts behind it? It
can not be guaranteed that the IPv6 address derived from so-called
reserved EUI-64 ID would not be used by any host behind the CLAT.
I.e., DAD is not avoidable.

Thanks,
washam

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 09:14:25 +0200

Le 2012-08-22 à 02:27, Lorenzo Colitti a écrit :

> On Wed, Aug 22, 2012 at 1:23 AM, Rémi Després <[email-masked]> wrote:
> Put one CLAT behind the other.

"On the same link" was part of the statement (which remains AFAIK remains a false statement).

> The first CLAT gets a /64 from upstream and passes it on to its downstream. The second CLAT gets the RA from the first with the same /64. Both are on the same /64. They both pick the same IID because that's what the draft tells them to do. Voila, the same IPv6 address is assigned to two hosts.

Cascading CLATs isn't part of the 464XLAT model where the WAN side is IPv6 only and the LAN side supports private IPv4.

RD

---

From: GangChen <[email-masked]>
Date: Wed, 22 Aug 2012 15:16:46 +0800

> address is assigned to two hosts.

   The scenario may be invalid in the case ND proxy, RFC4389 says
   "If an RA with the P bit set has arrived on a given interface
   (including the upstream interface) within the last 60 minutes, that
   interface MUST NOT be used as a proxy interface; i.e., proxy
   functionality is disabled on that interface. "

---

From: GangChen <[email-masked]>
Date: Wed, 22 Aug 2012 15:21:17 +0800

2012/8/22, Washam Fan <[email-masked]>:
>>>> No (and I'm not the one doing the implementation). The reasons why I
>>>> think we should not request IANA to allocate an IID are:
>>>>
>>>> 1. Operational experience that while it's good to ensure things are
>>>> unique by decree, in practice that leads to things not being unique some
>>>> of the time (e.g., MAC addresses - they're supposed to be duplicates,
>>>> but guess what, they're not). Thus, I prefer methods that are dynamic.

Avoiding DAD may not the point of reserved IID. A main advantage is to
fit the case where CLAT cannot perform ND Proxy. This was already
documented in the draft-07.

---

From: Washam Fan <[email-masked]>
Date: Wed, 22 Aug 2012 15:28:19 +0800

Hi,

> documented in the draft-07.
Then what if DAD fails due to some host behind CLAT already occupied
the address derived from the reserved IID?

Thanks,
washam

---

From: GangChen <[email-masked]>
Date: Wed, 22 Aug 2012 15:34:47 +0800

2012/8/22, Washam Fan <[email-masked]>:
>>>> - Each CLAT having its exclusive /64, any address derived from it
>>>> belongs
>>>> only to this CLAT, and cannot collide
>>>

RFC5342 keep the collision chance as small as it can.
Conversely, DAD would  fail when there is no ND proxy.
Which one is the best to you?

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 09:38:32 +0200

Le 2012-08-22 à 06:36, Washam Fan a écrit :

> What about the collision between the CLAT and the hosts behind it?

Different subject.

> It

As already said, no host that COMPLIES with the IPv6-addressing RFC (RFC4291) can collide with the CLAT. (The CLAT IID has been chosen for this.)

Now, it has been discussed that manual configuration permits to assign a host an address that doesn't comply with RFC4291. Right. But consequences of configuring an invalid address are numerous anyway, including various unreachability. No specific code is needed to try and prevent such consequences.

Besides, as already noted, RFC4862 says "if the duplicate link-local address is not formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned, IP operation on the interface MAY be continued". Thus, DAD doesn't firmly prohibit operation with a host that happens to use the CLAT IPv6 address. With the CLAT-assigned IID, there is no such concern.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 09:43:53 +0200

...
> the address derived from the reserved IID?

Unless the host has  been manually configured with an address that doesn't comply with RFC4291, this cannot happen. This is precisely what the CLAT IID ensures. 

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 10:05:25 +0200

Hi, James,

2012-08-21 22:52, james woodyatt:

> For my own part, I don't see why avoiding DAD should be a worthwhile objective unless the concern is about the time it takes to perform DAD while the address is still in the TENTATIVE state, to which I reply *cough* RFC 4429 *cough*.

The point isn't avoiding DAD (which is always present). It's making sure that DAD is irrelevant because hosts that have valid addresses (complying with RFC4291) have no risk to collide anyway. 
DAD does detect collisions, yes, but isn't sufficient to avoid their occurrence, and even operation with them for addresses "not formed from an interface identifier based on the hardware address".  

>  I am not sanguine about arguments that a Best Current Practice should recommend a work-around for an implementation issue in one particular platform that isn't generally required everywhere.

In my understanding, all valid technical concerns that have been expressed are covered if, in section 8.3.2, the first part of the following sentence is deleted:
"If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of the implementation, the CLAT may use a dedicated IANA assigned EUI-64 ID for creating a translated IPv6 address to be used in stateless translation [RFC6145]."

This permits your implementation to ignore the CLAT-assigned IID, if you so wish, and permits implementations that take advantage of it.

Regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Aug 2012 18:18:42 +0900

> "On the same link" was part of the statement (which remains AFAIK remains

If you put the two CLATs one behind the other, you have to connect them
using a link. Therefore, they are by definition on the same link..

> The first CLAT gets a /64 from upstream and passes it on to its
> downstream. The second CLAT gets the RA from the first with the same /64.
> Both are on the same /64. They both pick the same IID because that's what
> the draft tells them to do. Voila, the same IPv6 address is assigned to two
> hosts.
>
>
> Cascading CLATs isn't part of the 464XLAT model where the WAN side is IPv6
> only and the LAN side supports private IPv4.
>

But it can happen in practice, and in this model, using a reserved IID
breaks things, while using DAD does not.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Aug 2012 18:31:50 +0900

> the address derived from the reserved IID?

The same thing that happens if any a router fails to assign a global
address on an interface because a host already has that address.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Aug 2012 18:42:07 +0900

> documented in the draft-07.

Actually, I think a reserved IID does not help. Rationale:

1. If the CLAT's upstream interface is point-to-point (e.g., 3G), then
the CLAT does not need to perform ND proxying at all in order to provide
its clients with connectivity. All it needs to do is claim an IPv6 address
from the /64 and enable IPv6 forwarding. The important thing is not
proxying, but defending the address against DAD.

2. If the CLAT's upstream interface is not point-to-point, and the CLAT
doesn't perform ND proxying, then connectivity is broken anyway. Nodes on
the upstream interface and nodes on the downstream are on the same /64, but
they can't reach each other. So you already have a much bigger problem than
IID collisions, and a reserved IID will not fix it.

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 11:59:09 +0200

Le 2012-08-22 à 11:18, Lorenzo Colitti a écrit :

> On Wed, Aug 22, 2012 at 4:14 PM, Rémi Després <[email-masked]> wrote:
> If you put the two CLATs one behind the other, you have to connect them using a link. Therefore, they are by definition on the same link..
>  
> But it can happen in practice, and in this model, using a reserved IID breaks things, while using DAD does not.

You seem interested in pursuing this example where a CLAT would be activated on a dual-stack private network (i.e. out of scope for 464XLAT), behind a CLAT that, as requested by the draft, is activated on an IPv6-only network.
1. I don't see what should work and would be broken if either CLAT use the CLAT-reserved IID.
2. Unless you insist, I would be glad to stop spending time on this case. It is too far from the question at hand: is there any good reason to prohibit those for whom it is useful to use a reserved CLAT IID? 

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 12:03:29 +0200

Le 2012-08-22 à 11:42, Lorenzo Colitti a écrit :

> 1. If the CLAT's upstream interface is point-to-point (e.g., 3G), then the CLAT does not need to perform ND proxying at all in order to provide its clients with connectivity. All it needs to do is claim an IPv6 address from the /64 and enable IPv6 forwarding. The important thing is not proxying, but defending the address against DAD.
> 
> 2. If the CLAT's upstream interface is not point-to-point, and the CLAT doesn't perform ND proxying, then connectivity is broken anyway. Nodes on the upstream interface and nodes on the downstream are on the same /64, but they can't reach each other. So you already have a much bigger problem than IID collisions, and a reserved IID will not fix it.

Not sure to understand the case. 
Are you suggesting that the /64 assigned to a CLAT node is also a prefix valid on the upstream link?

RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Aug 2012 19:04:39 +0900

On Wed, Aug 22, 2012 at 6:59 PM, Rémi Després <[email-masked]>wrote:

> You seem interested in pursuing this example where a CLAT would be
> activated on a dual-stack private network (i.e. out of scope for 464XLAT),
> behind a CLAT that, as requested by the draft, is activated on an IPv6-only
> network.
>

I'm just pointing out a situation where a reserved IID can cause a problem.
You may call it a problem that's out of scope; I call it robust.

> 2. Unless you insist, I would be glad to stop spending time on this case.
> It is too far from the question at hand: is there any good reason to
> prohibit those for whom it is useful to use a reserved CLAT IID?
>

The fundamental problem is that I don't see where there is a use for a
reserved IID.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Aug 2012 19:06:14 +0900

> valid on the upstream link?

Yes, because GangChen was referring to the Proxy ND RFC, and that's the
basic scenario covered in that RFC.

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 12:13:35 +0200

Le 2012-08-22 à 12:06, Lorenzo Colitti a écrit :

> On Wed, Aug 22, 2012 at 7:03 PM, Rémi Després <[email-masked]> wrote:
> Yes, because GangChen was referring to the Proxy ND RFC, and that's the basic scenario covered in that RFC.

Proxy ND is a tool that excludes addresses other than that or those configured on the considered link.
Using it to exclude the CLAT WAN-side address can therefore be understood without suggesting that a provider assigns several addresses on a /64 it has assigned to one of its customers.

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 12:21:42 +0200

Le 2012-08-22 à 12:04, Lorenzo Colitti a écrit :

> On Wed, Aug 22, 2012 at 6:59 PM, Rémi Després <[email-masked]> wrote:
> I'm just pointing out a situation where a reserved IID can cause a problem. You may call it a problem that's out of scope; I call it robust.
>  
> The fundamental problem is that I don't see where there is a use for a reserved IID.

Good. This is different from suggesting that it would break something that should work. 

Yes, you and some others haven't seen such a use, but some others have identified such use for quite some time, as reflected the current draft.
Since the IID reservation doesn't hurt you in any way, time might be saved if you could just accept it with a MAY making its use optional.
This seems to me normal IETF consensus approach.

RD

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 22 Aug 2012 10:27:27 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Wednesday, August 22, 2012 6:06 AM
To: Rémi Després
Cc: Bjoern A. Zeeb; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-06.txt

>Yes, because GangChen was referring to the Proxy ND RFC, and that's the basic scenario covered in that RFC.

Maybe we just have a terminology issue.  When we speak of Proxy ND we are talking about a DAD Proxy and not an ND Proxy?

Please note ND Proxy is not a completely solved problem and that is why RFC 4389 is an Experimental RFC.  Erik Nordmark noted some issues in the past with RFC 4389.

"Issues with RFC 4389 such as weakness in loop avoidance. ND proxy in essence forwards IP (ND) packets without decrementing ttl, which can lead to catastrophic loops. The RFC tries to ameliorate that by detecting loops. However, the loop detection is based on receiving RAs (with the P-bit) which handles some cases. But it isn't robust against somebody connecting what was two Ethernet segments after ND proxy has sent its two P-bit RAs."

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Aug 2012 19:30:52 +0900

On Wed, Aug 22, 2012 at 7:21 PM, Rémi Després <[email-masked]>wrote:

> Yes, you and some others haven't seen such a use, but some others have
> identified such use for quite some time, as reflected the current draft.
>

The only thing I see in the current draft is:

    If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction
   of the implementation, the CLAT may use a dedicated IANA assigned
   EUI-64 ID

I think this text is incorrect for the reasons I listed above: if you have
a p2p upstream link you don't need to perform ND proxying, and if you don't
have a p2p upstream link, either you perform ND proxying or things break
pretty badly. Therefore, I think it should be removed.

If that text is removed, is there any other reason to reserve an IID?

---

From: GangChen <[email-masked]>
Date: Wed, 22 Aug 2012 19:39:42 +0800

2012/8/22, Lorenzo Colitti <[email-masked]>:
> from the /64 and enable IPv6 forwarding.

Would the purpose of "claim an IPv6 address" exclude the CLAT WAN-side
address (More precisely it is IPv6 address on a virtual interface) ?

> The important thing is not

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 13:58:54 +0200

Le 2012-08-22 à 12:30, Lorenzo Colitti a écrit :

> On Wed, Aug 22, 2012 at 7:21 PM, Rémi Després <[email-masked]> wrote:
> I think this text is incorrect for the reasons I listed above: if you have a p2p upstream link you don't need to perform ND proxying, and if you don't have a p2p upstream link, either you perform ND proxying or things break pretty badly. Therefore, I think it should be removed.
> 

1. As said in particular in my answer to James Woodyatt:
'In my understanding, all valid technical concerns that have been expressed are covered if, in section 8.3.2, the first part of the following sentence is deleted:
"If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of the implementation, the CLAT may use a dedicated IANA assigned EUI-64 ID for creating a translated IPv6 address to be used in stateless translation [RFC6145]."'

2. The next sentence in the draft gives this reason:
"This will allow the CLAT to avoid possible IPv6 address duplication issues between an IPv6 address for   stateless translation [RFC6145] in the CLAT and an IPv6 address assigned to native IPv6 nodes behind the CLAT." 
This is IMHO clear enough. (Could be editorially improved with s/an IPv6 address/the IPv6 address/ and s/native IPv6 nodes/a native IPv6 node/

RD

---

From: joel jaeggli <[email-masked]>
Date: Wed, 22 Aug 2012 06:10:23 -0700

On 8/22/12 3:21 AM, Rémi Després wrote:
>
> Since the IID reservation doesn't hurt you in any way, time might be 
> saved if you could just accept it with a MAY making its use optional.

It is not clear to me why you would reserve something that you don't 
need. I have to wonder what the IESG will thing of that.

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 16:06:08 +0200

Hi, Joel,

2012-08-22 15:10, joel jaeggli :

> It is not clear to me why you would reserve something that you don't need. I have to wonder what the IESG will thing of that.

The sentence you answer here was preceded by "you and some others haven't seen such a use, but some others have identified such use for quite some time, as reflected the current draft". 

This partial answer was expected to be sufficient in the context of what I was answering myself, but here is a self contained answer explaining what we need:

1. The draft itself explains, about the "IANA assigned EUI-64 ID": "This will allow the CLAT to avoid possible IPv6 address duplication issues between an IPv6 address for stateless translation [RFC6145] in the CLAT and an IPv6 address assigned to native IPv6 nodes behind the CLAT".

2. The proposed alternative, i.e. using DAD to deal with these duplications isn't a complete solution, in particular because a conflicting local-scope IID may have been assigned before 464XLAT is activated. Recommending to be on the safe side by using this IID is therefore arguably the right approach. 
Yet, it is a fact that some WG members want freedom of doing only DAD. This is why the NEED is limited to _permitting_ what some others see as the safe approach.  

3. Secondarily, implementations using the CLAT-reserved IID can arguably be considered simpler than without it. (There is apparently no consensus on this, but no consensus to the opposite either.)

Hope it clarifies.

Regards,
RD

---

From: Tom Taylor <[email-masked]>
Date: Wed, 22 Aug 2012 12:03:32 -0400

The normal IETF consensus approach is "rough consensus", not total 
consensus. I say again, if you are willing to make your reserved IID a 
MAY, it is definitely an option, and easily accommodated by a separate 
draft. That way the main draft is cleaner.

On 22/08/2012 6:21 AM, Rémi Després wrote:
...> Yes, you and some others haven't seen such a use, but some others
have identified such use for quite some time, as reflected the current
draft.
> saved if you could just accept it with a MAY making its use
> optional. This seems to me normal IETF consensus approach.
>
> RD
>
>
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 18:25:44 +0200

Le 2012-08-22 à 18:03, Tom Taylor a écrit :

> The normal IETF consensus approach is "rough consensus", not total consensus.

Clear to all of us, I think.

> I say again, if you are willing to make your reserved IID a MAY, it is definitely an option, and easily accommodated by a separate draft.

This seems to mean that, at least, you have no technical objection.

> That way the main draft is cleaner.

Different view.

Leaving room for ill controlled consequences in case of unlikely but possible collisions, and avoiding to document in the draft itself the known way to avoid "possible IPv6 address duplication issues between an IPv6 address for stateless translation [RFC6145] in the CLAT and an IPv6 address assigned to native IPv6 nodes behind the CLAT" wouldn't make the draft any cleaner.

(Trying to hide information by having it in a different place doesn't help RFC readers to understand what IETF is doing, IMHO.)

RD

---

From: Tom Taylor <[email-masked]>
Date: Wed, 22 Aug 2012 12:33:33 -0400

...

> This seems to mean that, at least, you have no technical objection.
...
[PTT] The technical objection is that you are introducing brittleness by 
specifying a well-known IID. There are circumstances (already described 
and potentially lurking) where that can cause trouble.

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Aug 2012 18:39:36 +0200

Le 2012-08-22 à 18:33, Tom Taylor a écrit :

> [PTT] The technical objection is that you are introducing brittleness by specifying a well-known IID. There are circumstances (already described and potentially lurking) where that can cause trouble.

None of these "circumstances" has been documented to a point where it could be understood.
AFAIK, they don't exist.

RD

---

From: james woodyatt <[email-masked]>
Date: Wed, 22 Aug 2012 10:54:55 -0700

> This permits your implementation to ignore the CLAT-assigned IID, if you so wish, and permits implementations that take advantage of it.

Here's my concern.  Do I need to modify all my host implementations that don't know anything about 464XLAT—- and hopefully will never need to know anything about them-- so that they disallow manual configuration of the IID reserved by IANA for this purpose?  If so, then that's a price that I think is far too high for this draft to ask to be paid by every IPv6 host implementation in the world that might ever find itself behind a 464XLAT router, and I would oppose publication for that reason.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 22 Aug 2012 20:48:11 +0200

The proposed reservation is already taken from an existing IANA reserved 
range of Modified EUI-64 from rfc5342#section-2.2.2

Dumb question: why would you have to take any (new) special action due 
to publication of 464xLAT?

Presumably you already protect against manually assigning these 
accidentally?

james woodyatt wrote:
> On Aug 22, 2012, at 01:05 , Rémi Després<[email-masked]>  wrote:
> james woodyatt<[email-masked]>

---

From: james woodyatt <[email-masked]>
Date: Wed, 22 Aug 2012 12:21:37 -0700

On Aug 22, 2012, at 11:48 , Ray Hunter <[email-masked]> wrote:
> 
> Dumb question: why would you have to take any (new) special action due to publication of 464xLAT?

Stupid answer: now that I have been made properly aware of this reserved IID range, I suppose my technical concern is already addressed.

Still, I remain unpersuaded on procedural grounds, because it seems to me that consumption of this reserved IID in a BCP is not well justified by the objective of accommodating the peculiar limitations of a certain platform architecture.  Rather, I should think that best current practice would be to fix the platform to remove the limitation, no?

> Presumably you already protect against manually assigning these accidentally?

One might presume.  I'll have to check.  Separable problem, I guess.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Aug 2012 10:35:04 +0900

On Wed, Aug 22, 2012 at 11:06 PM, Rémi Després <[email-masked]>wrote:

> here is a self contained answer explaining what we need:
>

Ok, so let me parse this out clearly so we're sure we're all discussing the
same thing.

> 1. The draft itself explains, about the "IANA assigned EUI-64 ID": "This
> will allow the CLAT to avoid possible IPv6 address duplication issues
> between an IPv6 address for stateless translation [RFC6145] in the CLAT and
> an IPv6 address assigned to native IPv6 nodes behind the CLAT".
>

Ok. So this point is not an argument in support of the reserved IID
solution. It's a problem statement. What it says is, "we need to avoid
address duplication issues between the CLAT and its clients." It doesn't
advocate a particular solution. Both DAD and a reserved interface IDs are
solutions. (I would argue that a reserved IID is much more brittle, and
requires needless red tape, so it's a worse solution, but let's ignore that
point for now.) We all agree that this is a problem statement; we only
disagree on how to solve it. So there's no need to discuss this point
further.

2. The proposed alternative, i.e. using DAD to deal with these duplications
> isn't a complete solution, in particular because a conflicting local-scope
> IID may have been assigned before 464XLAT is activated. Recommending to be
> on the safe side by using this IID is therefore arguably the right approach.
>

Ok, so this is your argument #1.

3. Secondarily, implementations using the CLAT-reserved IID can arguably be
> considered simpler than without it. (There is apparently no consensus on
> this, but no consensus to the opposite either.)
>

Ok. So this is your argument #2.

In summary, you're arguing that a reserved ID is necessary for two reasons:

1. If you don't have a reserved IID, the CLAT might not be able to provide
service to a client, since that client might already have formed an IPv6
address using that IID.
2. If you use a reserved IID, it simplifies implementation.

Do you agree that this is a summary of your arguments for using a reserved
IID? If so:

- I really don't think #1 makes sense. You might as well say, "we need to
reserve an IID range for routers, because otherwise, a router's IIDs might
already have been taken by a host on the link when the router is switched
on, and the router wouldn't be able to provide service to hosts". We don't
do that for routers. Why should we do it for the CLAT?
- I don't think #2 makes much sense either. The CLAT already has a DAD
implementation, because it's an IPv6 node. I think it's not that hard to
make the CLAT respond to DAD for the other address as well - it's probably
just a matter of assigning it to the downstream interface and letting the
kernel handle DAD. In the standard tethering scenario, you can also avoid
this by simply configuring your address before you send the RA.

---

From: GangChen <[email-masked]>
Date: Thu, 23 Aug 2012 12:43:44 +0800

> proxying, but defending the address against DAD.

The statement of "The important thing is not proxying, but defending
the address against DAD" is arguable to what an ND proxy exactly is.
It seems to me that is a DAD proxy behaviour, since the purpose is to
defend an IPv6 address used on the WAN site of CLAT.

It's also unclear to me how to implement it without RFC4389. It
probably likes you said in another mail "it's probably just a matter
of assigning it to the downstream interface and letting the kernel
handle DAD". But it would be great if someone could share more
experiences to confirm that is a doable way.

Many thanks

Gang

---

From: Ray Hunter <[email-masked]>
Date: Thu, 23 Aug 2012 08:39:05 +0200

I've been lurking on this draft.

The allocation of the reserved IID is problematic for me.

I still don't understand how allocation of a reserved IID will always 
guarantee that 464xlat will work as designed. Especially since I'd 
expect to find a list of necessary restrictions and assumptions on the 
CLAT to guarantee correct operation of 464xlat e.g. location in the 
network, cascading of devices, or number of CLAT's per device. But these 
do not seem to be fully defined in the current draft.

Equally, I don't understand what would break if the reserved IID was 
removed from the draft.

The intention behind RFC5342 seems to suggest that reserved IID 
parameters are assigned "by Expert Review"

I don't feel I can perform expert review of this point at this time.

I'll send nits in a separate post.
> james woodyatt <mailto:[email-masked]>
> 22 August 2012 21:21
> On Aug 22, 2012, at 11:48 , Ray Hunter<[email-masked]>  wrote:
> ------------------------------------------------------------------------

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Aug 2012 08:58:38 +0200

> Here's my concern.  Do I need to modify all my host implementations that don't know anything about 464XLAT—- and hopefully will never need to know anything about them-- so that they disallow manual…

The fact is that, as noted by Ray and as you acknowledged, nothing needs to be done in your host implementation.
Other considerations will be addressed separately.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Aug 2012 09:16:54 +0200

2012-08-22 à 21:21, james woodyatt:

> Still, I remain unpersuaded on procedural grounds, because it seems to me that consumption of this reserved IID in a BCP is not well justified by the objective of accommodating the peculiar limitations of a certain platform architecture.

Instead of being a solution for a platform-specific problem, it is a general solution to make the 464XLAT solution simpler and more complete (yet letting those who prefer the less complete solution to choose it).
For those who take the complete solution, cost of supporting it is negligible once IANA has registered the IETF requested IID (see in particular www.ietf.org/mail-archive/web/v6ops/current/msg12679.html)

>  Rather, I should think that best current practice would be to fix the platform to remove the limitation, no?
> 

AFAIK, you don't need a specific protection against this particular manual misconfiguration, not more than, for example, another manual misconfiguration where some host would use an EUI IID with a MAC address that isn't its own.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Aug 2012 11:04:39 +0200

Lorenzo,

Le 2012-08-23 à 03:35, Lorenzo Colitti a écrit :

> On Wed, Aug 22, 2012 at 11:06 PM, Rémi Després <[email-masked]> wrote:
> Ok, so let me parse this out clearly so we're sure we're all discussing the same thing.
>  
> Ok. So this point is not an argument in support of the reserved IID solution. It's a problem statement. What it says is, "we need to avoid address duplication issues between the CLAT and its clients." It doesn't advocate a particular solution. Both DAD and a reserved interface IDs are solutions. (I would argue that a reserved IID is much more brittle, and requires needless red tape, so it's a worse solution, but let's ignore that point for now.) We all agree that this is a problem statement; we only disagree on how to solve it. So there's no need to discuss this point further.

(a) This sentence you call a "problem statement" is placed as an explanation of why "IANA assigned EUI-64 ID" is useful.
As such it does identify how to solve the identified problem.
 
(b) IETF assigning one value in a range already "available for allocation" shouldn't be a big deal. (What would be the purpose of such a range in RFC5342 if using it would be considered such excessive "red tape" that its use would be prevented.) 

(c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely without waiting for IANA having completed its registration. Actually, it has already been done, successfully AFAIK (http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html).

> Ok, so this is your argument #1.

Right.
Reserved IID provides a more complete protection against collisions, in particular in this case.

> Ok. So this is your argument #2.

The only point is that there is no implementation difficulty for those who are interested in point 1.

> 1. If you don't have a reserved IID, the CLAT might not be able to provide service to a client, since that client might already have formed an IPv6 address using that IID.
> Do you agree that this is a summary of your arguments for using a reserved IID? If so:

Point 1 is better expressed above  
Point 2 is that just that there is no implementation difficulty.

There are other considerations, but these are in my understanding sufficient. Let's deal with them.

> - I really don't think #1 makes sense. You might as well say, "we need to reserve an IID range for routers, because otherwise, a router's IIDs might already have been taken by a host on the link when the router is switched on, and the router wouldn't be able to provide service to hosts". We don't do that for routers. Why should we do it for the CLAT?

1. You criticize my point by suggesting that I might have made another point which doesn't make sense. This  isn't good logic AFAIAC.

2. Routers that use EUI IIDs have normally no collision problem because appropriately-configured host cannot collide. (What they do in case of a manually misconfigured host creating a collision on this IID with such an address isn't clear, at last to me, but this isn't the subject.)
Routers that use local-scope IID (are there many, I don't know) should better prepared to finding a colliding host. They should then take another value. 
I therefore agree that there is no sense in what you say I "might as well say".  But the fact is that I don't say it.

> - I don't think #2 makes much sense either. The CLAT already has a DAD implementation, because it's an IPv6 node. I think it's not that hard to make the CLAT respond to DAD for the other address as well - it's probably just a matter of assigning it to the downstream interface and letting the kernel handle DAD. In the standard tethering scenario, you can also avoid this by simply configuring your address before you send the RA.

The DAD, indeed needs to be present, no problem here.
But AFAIK you propose the CLAT-node DAD to exclude, at its LAN-side interface, not only all its LAN-side addresses, but also its 464XLAT WAN-side address. At a given interface, DAD normally excludes all addresses that are configured on this interface, and only these. Configuring the CLAT-WAN-side address on the LAN-side interface would be a hack whose consequences haven't been analyzed AFAIK. Avoiding it by using the reserved IID is IMHO good design.

Regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Aug 2012 18:41:42 +0900

On Thu, Aug 23, 2012 at 6:04 PM, Rémi Després <[email-masked]>wrote:
>
> (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely without
> waiting for IANA having completed its registration. Actually, it has
> already been done, successfully AFAIK (
> http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html<http://www.ietf.org/mail-archive/web/v6ops/current/msg12679.html>
> ).
>

Excuse me, but that's absurd. First you say that using an IID in the
reserved range is useful because it guarantees collisions, and then you say
that an implementation just picked a random number from this range and
that's fine? What if that number is assigned and the implementation is not
updated? You encounter the very problem that you want to solve by using a
reserved IID.

> 1. You criticize my point by suggesting that I might have made another
> point which doesn't make sense. This  isn't good logic AFAIAC.
>

Nope. I criticise your point by pointing out that in a basically identical
problem (a router is turned on and a host on the link has already picked an
IPv6 address with the same IID), we chose to design DAD instead of using
reserved interface IDs.

> 2. Routers that use EUI IIDs have normally no collision problem because
> appropriately-configured host cannot collide. (What they do in case of a
> manually misconfigured host creating a collision on this IID with such an
> address isn't clear, at last to me, but this isn't the subject.)
>

And the CLAT is not a router? I mean - what's different to the scenario
above where the router is powered up?

> Routers that use local-scope IID (are there many, I don't know)
>

Yes. On routers, people like to configure their interface IDs manually so
they can do things like have router IP addresses that don't change when MAC
addresses change (e.g., when interface cards are swapped). Then they can
put them in DNS.

> should better prepared to finding a colliding host.
>

And the CLAT is not a router? I mean - what's different to the scenario
above where the router is powered up?

> But AFAIK you propose the CLAT-node DAD to exclude, at its LAN-side
> interface, not only all its LAN-side addresses, but also its 464XLAT
> WAN-side address. At a given interface, DAD normally excludes all addresses
> that are configured on this interface, and only these. Configuring the
> CLAT-WAN-side address on the LAN-side interface would be a hack whose
> consequences haven't been analyzed AFAIK.
>

I don't think it's a hack. It's no different than doing "interface clat0
unnumbered wlan0". And it's only one way of doing t

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Aug 2012 12:00:27 +0200

Le 2012-08-23 à 11:41, Lorenzo Colitti a écrit :

> On Thu, Aug 23, 2012 at 6:04 PM, Rémi Després <[email-masked]> wrote: 
> Excuse me, but that's absurd. First you say that using an IID in the reserved range is useful because it guarantees collisions, and then you say that an implementation just picked a random number from this range and that's fine? What if that number is assigned and the implementation is not updated? You encounter the very problem that you want to solve by using a reserved IID.

AFAIK, a value requested by IETF that doesn't conflict with anything in IANA, is just accepted by IANA.
Unless there would be somewhere in IETF a parallel request for the same value (which isn't the case) theer is therefore no problem.

> Nope. I criticise your point by pointing out that in a basically identical problem (a router is turned on and a host on the link has already picked an IPv6 address with the same IID), we chose to design DAD instead of using reserved interface IDs.
>  
> And the CLAT is not a router? I mean - what's different to the scenario above where the router is powered up?
>  
> Yes. On routers, people like to configure their interface IDs manually so they can do things like have router IP addresses that don't change when MAC addresses change (e.g., when interface cards are swapped). Then they can put them in DNS.

Unmanaged CPEs wouldn't be concerned I suppose.
Anyway, but thanks for the useful info.

> And the CLAT is not a router?

CLAT nodes can be routers, for sure, and this discussion is mainly about them.

> I mean - what's different to the scenario above where the router is powered up?
>  
> But AFAIK you propose the CLAT-node DAD to exclude, at its LAN-side interface, not only all its LAN-side addresses, but also its 464XLAT WAN-side address. At a given interface, DAD normally excludes all addresses that are configured on this interface, and only these. Configuring the CLAT-WAN-side address on the LAN-side interface would be a hack whose consequences haven't been analyzed AFAIK.
> 
> I don't think it's a hack. It's no different than doing "interface clat0 unnumbered wlan0". And it's only one way of doing t

Which way applies to which device, or may be difficult to apply, isn't a concern if the reserved IID is used.

RD

---

From: GangChen <[email-masked]>
Date: Thu, 23 Aug 2012 18:54:37 +0800

> unnumbered wlan0". And it's only one way of doing t

ip unnumbered only makes sense for point-to-point interface AFAIK.
But the borrowed IP address is used to a tun device.
Not sure your recommendation could be used in 464xlat implementation.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Aug 2012 19:58:47 +0900

> Not sure your recommendation could be used in 464xlat implementation.

But a tun device *is* a point-to-point interface, right?

---

From: GangChen <[email-masked]>
Date: Thu, 23 Aug 2012 23:55:53 +0800

> But a tun device *is* a point-to-point interface, right?

Right
Assuming the borrowed IP address used to a tun device,
I'm just trying to figure out how to implement
If the CLAT's upstream is 3GPP access,
there are two point-to-point interfaces on CLAT if I understood correctly.
One is the Tun device(virtual interface) and another is 3GPP
interface(physical interface).
"interface clat0 unnumbered wlan0" lets ip address on wlan0 assigned
to a tun interface.
However, I guess 3GPP interface needs its own IP address in that case
Afterall, it is unavoidable there will be an address needs ND proxy.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 23 Aug 2012 18:20:03 +0200

inline

Rémi Després wrote:
>> On Thu, Aug 23, 2012 at 6:04 PM, Rémi Després 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     (c) 02-00-5E-10--00-00-00-00 can be used as reserved IID safely
>>     without waiting for IANA having completed its registration.
>>     Actually, it has already been done, successfully AFAIK
>>     (http://www.ietf.org/mail-archive/web/v6ops/current/msg12901.html
>>     <http://www.ietf.org/mail-archive/web/v6ops/current/msg12679.html>).
>>
>>
>> reserved range is useful because it guarantees collisions, and then 
>> you say that an implementation just picked a random number from this 
>> range and that's fine? What if that number is assigned and the 
>> implementation is not updated? You encounter the very problem that 
>> you want to solve by using a reserved IID.
>
> Unless there would be somewhere in IETF a parallel request for the 
> same value (which isn't the case) theer is therefore no problem.
>
>
Are you saying that there can only be ONE CLAT active on any given L2 
link (whether virtual or otherwise) when the reserved IID is used?

Seems to me 2 CLATs using a single reserved IID address with manual 
configuration are guaranteed to generate duplicate IPv6 addresses if 
they are connected to the same L2 link.

So in a high availability situation of 2 CLATs running in parallel 
(active active mode) using the reserved IID would be a problem?

Are you also saying that 2 CLAT's cannot be cascaded when using the 
reserved IID?

[because as I read it, the downlink IID has to be disjoint from any IID 
used on the upstream interface when attempting to share a single /64 
across 2 interfaces, and the upstream CLAT would have already claimed 
the reserved IID that the downstream CLAT wanted to use on its 
downstream interface]

How would inappropriate cascading or parallel connections be detected 
and the downstream/parallel CLAT disabled?
[I'm especially thinking VM's and virtual networks]

IMHO If these restrictions with the reserved IID are correct, then the 
draft should say also note this, and also any requirements on the 
implementation on what action to take in these situations.

I think that's one of Lorenzo's basic points, and I can't say reading 
your answer above how I can disagree with him.
>>
>>>     - I really don't think #1 makes sense. You might as well say,
>>>     "we need to reserve an IID range for routers, because otherwise,
>>>     a router's IIDs might already have been taken by a host on the
>>>     link when the router is switched on, and the router wouldn't be
>>>     able to provide service to hosts". We don't do that for routers.
>>>     Why should we do it for the CLAT?
>>
>>     1. You criticize my point by suggesting that I might have made
>>     another point which doesn't make sense. This  isn't good logic
>>     AFAIAC.
>>
>>
>> Nope. I criticise your point by pointing out that in a basically 
>> identical problem (a router is turned on and a host on the link has 
>> already picked an IPv6 address with the same IID), we chose to design 
>> DAD instead of using reserved interface IDs.
>>
>>     2. Routers that use EUI IIDs have normally no collision problem
>>     because appropriately-configured host cannot collide. (What they
>>     do in case of a manually misconfigured host creating a collision
>>     on this IID with such an address isn't clear, at last to me, but
>>     this isn't the subject.)
>>
>>
>> And the CLAT is not a router? I mean - what's different to the 
>> scenario above where the router is powered up?
>>
>> Yes. On routers, people like to configure their interface IDs 
>> manually so they can do things like have router IP addresses that 
>> don't change when MAC addresses change (e.g., when interface cards 
>> are swapped). Then they can put them in DNS.
>
>>     But AFAIK you propose the CLAT-node DAD to exclude, at its
>>     LAN-side interface, not only all its LAN-side addresses, but also
>>     its 464XLAT WAN-side address. At a given interface, DAD normally
>>     excludes all addresses that are configured on this interface, and
>>     only these. Configuring the CLAT-WAN-side address on the LAN-side
>>     interface would be a hack whose consequences haven't been
>>     analyzed AFAIK.
>>
>>
>> I don't think it's a hack. It's no different than doing "interface 
>> clat0 unnumbered wlan0". And it's only one way of doing t
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Aug 2012 19:19:09 +0200

Hi, Ray,

2012-08-23 18:20, Ray Hunter :

>>> On Thu, Aug 23, 2012 at 6:04 PM, Rémi Després <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

> Are you saying that there can only be ONE CLAT active on any given L2 link (whether virtual or otherwise) when the reserved IID is used?

NO.

Two CLAT nodes connected to a common WAN link will be delegated different IPv6 prefixes. Their CLAT IPv6 addresses will have the same IID but will be different.

Two CLAT nodes connected to a common LAN-side link would have CLAT IPv6 addresses also based on different IPv6 prefixes. 

> Seems to me 2 CLATs using a single reserved IID address with manual configuration are guaranteed to generate duplicate IPv6 addresses if they are connected to the same L2 link.

A single reserved IID doesn't mean a single reserved address.

> So in a high availability situation of 2 CLATs running in parallel (active active mode) using the reserved IID would be a problem?

No address problem AFAIK (but OTOH need to continuously synchronize the two NAT44s) 

> Are you also saying that 2 CLAT's cannot be cascaded when using the reserved IID?
> 
> [because as I read it, the downlink IID has to be disjoint from any IID used on the upstream interface when attempting to share a single /64 across 2 interfaces, and the upstream CLAT would have already claimed the reserved IID that the downstream CLAT wanted to use on its downstream interface]
> 
> How would inappropriate cascading or parallel connections be detected and the downstream/parallel CLAT disabled?
> IMHO If these restrictions with the reserved IID are correct, then the draft should say also note this, and also any requirements on the implementation on what action to take in these situations.

Well, cascaded CLATs are clearly out of scope for this draft. (CLATs are v6-only WAN side, and v6+v4p LAN side).

Even if the scope would be extended to support cascaded 464XLAT domains (in a way to be defined), any problem that exists with a reserved IID can also exist with IIDs in which the NAT44 external address is embedded (the proposal if no reserved IID is used). Without administratively configured parameters, these external addresses can typically be the same in various CLAT implementations.

> I think that's one of Lorenzo's basic points, and I can't say reading your answer above how I can disagree with him.

My answer above only concerned Lorenzo's objection that the supposed "red tape" that an IID reservation would need makes it impracticable.

Let me then add, about his objection above, that:
- The considered implementation (which apparently he would be happy to ignore) didn't take a value "at random" in the available range. It just took the first value, as one usually does.
- There is no risk that this value would need to be changed later on, because no other WG currently envisages such a reservation. First come first served.

Regards,
RD

---

From: Ray Hunter <[email-masked]>
Date: Thu, 23 Aug 2012 19:50:28 +0200

Thanks. So to be clear: the reserved IID would NOT be used for any L2 
addressing: just generating an IPv6 address (from the delegated prefix 
that is unique per CLAT)?

Otherwise L2 bridges and other devices might get confused (with side 
changes and duplicate EUI64 addresses appearing on multiple ports)

Thinking wireless LTE phone (with built in CLAT) connected to a L2 
switch in parallel with Homenet wired router (with built in CLAT)

> Rémi Després <mailto:[email-masked]>
> 23 August 2012 19:19
> Hi, Ray,
>
>>>> On Thu, Aug 23, 2012 at 6:04 PM, Rémi Després<[email-masked]<mailto:[email-masked]>>  wrote:
>>>>

---

From: jouni korhonen <[email-masked]>
Date: Fri, 24 Aug 2012 00:56:07 +0300

On Aug 22, 2012, at 1:30 PM, Lorenzo Colitti wrote:

> I think this text is incorrect for the reasons I listed above: if you have a p2p upstream link you don't need to perform ND proxying,

Just for my understanding how this in cellular uplink case would be different from RFC4389 scenario 2 (where the upstream is PPP)?

- Jouni

> and if you don't have a p2p upstream link, either you perform ND proxying or things break pretty badly. Therefore, I think it should be removed.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 Aug 2012 10:12:12 +0900

On Fri, Aug 24, 2012 at 2:19 AM, Rémi Després <[email-masked]>wrote:

> - The considered implementation (which apparently he would be happy to
> ignore) didn't take a value "at random" in the available range. It just
> took the first value, as one usually does.
> - There is no risk that this value would need to be changed later on,
> because no other WG currently envisages such a reservation. First come
> first served.
>

Remi, you can't say "these numbers are reserved by IANA", and then say
"first come first served". If they are assigned by IANA, you *can't use
them* until IANA reserves them, period.

If you put one of these numbers in an implementation, you're squatting on a
number that IANA has the freedom to assign whenever it wants. As soon as
assigns it (which it can and will do with no obligation to tell you), you
are in violation of that assignment.

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Aug 2012 08:02:39 +0200

2012-08-24 03:12, Lorenzo Colitti :

> On Fri, Aug 24, 2012 at 2:19 AM, Rémi Després <[email-masked]> wrote:
> Remi, you can't say "these numbers are reserved by IANA", and then say "first come first served". If they are assigned by IANA, you *can't use them* until IANA reserves them, period.

AFAIK, when the RFC is published, IANA acceptance of documented values has been checked.
Anticipating on RFC publication is each-one's responsibility. 
Since using the CLAT-specific IID is optional, which it will be with the proposed MAY, any vendor remains free not to use it before RFC publication more than ever.

> If you put one of these numbers in an implementation, you're squatting on a number that IANA has the freedom to assign whenever it wants. As soon as assigns it (which it can and will do with no obligation to tell you), you are in violation of that assignment.

AFAIK, IANA doesn't assign any value without prior IETF request to do it. 
If you have indication of the contrary, thanks for sharing this information.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Aug 2012 08:02:49 +0200

2012-08-23 19:50, Ray Hunter :

> Thanks. So to be clear: the reserved IID would NOT be used for any L2 addressing: just generating an IPv6 address (from the delegated prefix that is unique per CLAT)?

Right.

RD

> 
> Otherwise L2 bridges and other devices might get confused (with side changes and duplicate EUI64 addresses appearing on multiple ports)
> 
> Thinking wireless LTE phone (with built in CLAT) connected to a L2 switch in parallel with Homenet wired router (with built in CLAT)
>

---

From: Dan Drown <[email-masked]>
Date: Fri, 24 Aug 2012 10:36:55 -0500

Quoting jouni korhonen <[email-masked]>:
> Just for my understanding how this in cellular uplink case would be  
> different from RFC4389 scenario 2 (where the upstream is PPP)?

RFC4389 scenario 2 is built on the assumption that the same /64 is on  
both sides of the ppp link.  Cell network p2p case is the entire /64  
is routed to the handset, and there is no "rest of network" accross  
the cell uplink to proxy NDs from tethered clients.

---

From: Dan Drown <[email-masked]>
Date: Fri, 24 Aug 2012 11:02:58 -0500

> side, then it must make sure to reply to DAD on that address"?

You are correct that a EUI-64 isn't required to make 464xlat possible.  
  Responding to DAD (using proxy ND) is another way to solve this  
problem.

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Aug 2012 19:12:26 +0200

2012-08-24 18:02, Dan Drown :

> You are correct that a EUI-64 isn't required to make 464xlat possible.  Responding to DAD (using proxy ND) is another way to solve this problem.

Note that your proposal (with proxy ND) differs Lorenzo's who said "the CLAT does not need to perform ND proxying". 
One can try, as you suggest, to avoid limitations of DAD alone by adding ND proxy. 
However:

1. ND proxy if for link-layer bridges (RFC 4389).  Addresses that are refused by the DAD of an ND proxy at an interface are accepted as destinations through that interface, while the CLAT IPv6 address MUST NOT be an accepted destination bridged to the CLAT. Using ND proxy to exclude this address is therefore out of ND-proxy scope. Some hack would need to be added for its use in 464XLAT. (Besides, this doesn't solve the issue of a host having the CLAT IPv6 address before 464XLAT is activated).

2. With a CLAT-specific EUI-64 there is no such problem(. DAD works as usual; no ND proxy is needed; no host may have the CLAT IPv6 address. 
All what is necessary is reserving a value in in a range already available for such reservations (a trivial thing to do once decided).
 
=> The CLAT EUI-64 is required to permit those who prefer a simple and safe implementation to have it.

Anything missed?

Regards,
RD

---

From: jouni korhonen <[email-masked]>
Date: Sat, 25 Aug 2012 12:20:51 +0300

On Aug 24, 2012, at 6:36 PM, Dan Drown wrote:

> RFC4389 scenario 2 is built on the assumption that the same /64 is on both sides of the ppp link.  Cell

Ok. that clarifies. thanks,

- jouni

>  network p2p case is the entire /64 is routed to the handset, and there is no "rest of network" accross the cell uplink to proxy NDs from tethered clients.