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

From: joel jaeggli <[email-masked]>
Date: Sun, 02 Sep 2012 10:09:52 -0700

Reminder, this WGLC runs through the 5th of September.

On 8/21/12 8:45 AM, Fred Baker (fred) wrote:
> This is to open a two week Working Group last Call on
>
> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
>    "464XLAT: Combination of Stateful and Stateless Translation", Masataka
>    Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12
>
> Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 3 Sep 2012 17:17:57 +0200

> Reminder, this WGLC runs through the 5th of September.

Thanks for the reminder.

If the WGLC is, like an IESG last call, "to make sure that no important concerns have been missed or misunderstood" (RFC 2418), I think we aren't quite at this stage yet.
The current discussions on ND proxy and/or IANA-reserved IIDs is still progressing, but AFAIK without clear conclusion.

What is the normal procedure then is unclear to me, but trying to quickly reach common WG understanding on this subject would certainly make sense.

Regards,
RD

---

From: joel jaeggli <[email-masked]>
Date: Mon, 03 Sep 2012 09:37:35 -0700

> The current discussions on ND proxy and/or IANA-reserved IIDs is still progressing, but AFAIK without clear conclusion.
It is not your job to determine what to do with the results.

---

From: Rémi Després <[email-masked]>
Date: Mon, 3 Sep 2012 22:15:46 +0200

> It is not your job to determine what to do with the results.

Didn't claim it was my job!
My responsibility is limited to sharing important facts I know to be true (or believe to be true). 
What the chairs do with them is undoubtedly their responsibility.

Provided IESG members can make their decisions with enough understanding of debated issues, there is no problem.

Regards,
RD

---

From: t.petch <[email-masked]>
Date: Tue, 4 Sep 2012 10:02:32 +0100

----- Original Message -----
From: "joel jaeggli" <[email-masked]>
To: "Rémi Després" <[email-masked]>
Cc: "v6ops WG" <[email-masked]>
Sent: Monday, September 03, 2012 5:37 PM
On 9/3/12 8:17 AM, Rémi Després wrote:
> If the WGLC is, like an IESG last call, "to make sure that no
important concerns have been missed or misunderstood" (RFC 2418), I
think we aren't quite at this stage yet.
> The current discussions on ND proxy and/or IANA-reserved IIDs is still
progressing, but AFAIK without clear conclusion.

<tp>
Very true, for me as for Remi, but it does affect my views.  Prior to
the WGLC, the document looked ok, from the perspective of my
predominantly 'wired' background.  The extensive (intensive?) list
discussion of technical matters seems to me to say that there are
unresolved issues, that the I-D does not define well enough the
environment into which it is going to slot (e.g. tethering, DHCPv6-PD).
Hence it should not progress just yet.

Trouble is, in coming to this conclusion, I am, inevitably, making my
own rough consensus call on that list discussion, which I have to do
without knowing what the official consensus call will later be.

Tom Petch

> What is the normal procedure then is unclear to me, but trying to
quickly reach common WG understanding on this subject would certainly
make sense.
>>> Please read it now. We are interested in, among other things,
technical commentary on the draft and the working group's perception on
its usefulness to its target audience.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Sep 2012 13:59:39 +0000

On Sep 4, 2012, at 5:02 AM, t.petch <[email-masked]<mailto:[email-masked]>> wrote:
Trouble is, in coming to this conclusion, I am, inevitably, making my
own rough consensus call on that list discussion, which I have to do
without knowing what the official consensus call will later be.

Normally, if you are aware of problems with the document, or think it's a bad solution, you say so on the mailing list.   You do not try to gauge consensus—you participate in the discussion, and by so doing, improve the document.   That's how we get better documents!

---

From: t.petch <[email-masked]>
Date: Tue, 4 Sep 2012 18:36:36 +0100

---- Original Message -----
From: "Ted Lemon" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "joel jaeggli" <[email-masked]>; "Rémi Després"
<[email-masked]>; "v6ops WG" <[email-masked]>
Sent: Tuesday, September 04, 2012 2:59 PM
On Sep 4, 2012, at 5:02 AM, t.petch wrote:
Trouble is, in coming to this conclusion, I am, inevitably, making my
own rough consensus call on that list discussion, which I have to do
without knowing what the official consensus call will later be.

Normally, if you are aware of problems with the document, or think it's
a bad solution, you say so on the mailing list.   You do not try to
gauge consensus—you participate in the discussion, and by so doing,
improve the document.   That's how we get better documents!

<tp>
I have already said, in response to Joel's question, that I think that
the document should not go forward as is; rephrasing that statement, I
am saying that there are problems with the document.

Initially, I thought that the solution looked good but as more has come
to light (e.g. about tethering, Proxy ND, DHCP-PD), the solution seems
lacking, that there are unresolved issues that need to be resolved and I
would expect this to be obvious to most of those who have followed the
discussion; if it isn't, then simply restating what has been said here
already is not going to change things.  I do not have any more problems
to add.

So, based on the obvious, I think that this I-D is not yet ready to
progress.

Yes, that is a judgement call, but then so is is everyone else's view of
whether or not this I-D should proceed which is the point at question.
Some of it is based on engineering, some of it is not; that's life!

Tom Petch

---

From: Ray Hunter <[email-masked]>
Date: Wed, 05 Sep 2012 07:24:02 +0200

I have read this draft and lurked the on-list discussion.

Comments based on version 07 
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07

Following all IMVVHO [I'm no XLAT expert]

1) The need for 464XLAT is clear.

2) The basic 464xlat architecture is sound and certainly worthy of 
advancement and further refinement.
The authors have done a great job on what is a very tricky problem.

3) Inclusion of ND Proxy [RFC4389] is problematic for 2 reasons:
Firstly ND Proxy is an experimental protocol, whereas the draft is 
aiming to become BCP.

Secondly, ND Proxy has inadequate loop detection, prevention and 
mitigation, for it to be reliably deployed in tethered networks 
consisting of multiple devices.  If 464XLAT is going to be effective, it 
will need to be incorporated into CPE devices. Section 4.1.3.3 of 4389 
is a potential source of oscillation, instability, unpredictable 
behaviour, and provides a DoS vector, if 464XLAT were to be widely 
incorporated into consumer devices. [Authors claim multiple device 
working is out of scope, but this situation will likely happen in home 
use) ]

4) Section 8.3.2 does not adequately deprecate single /64 working, which 
I consider harmful (as per BCP157).

5) Assignment of a single special-purpose IANA IID is problematic for 2 
reasons.

I don't consider the document complies with the spirit of justifying the 
Modified EUI-64 identifier via expert review (RFC5342 Section 5.1), in 
that the argumentation for assignment is very opaque, and the use-case 
is not completely defined e.g. the IID SHOULD NOT be used for L2 
addressing by the CLAT.

There is no detection or protection for cascaded CLATs, where if the 
IPv6 address is assigned using the Modified EUI-64 identifier to a 
downstream CLAT, this will clash with the upstream CLAT if it has also 
used the Modified EUI-64 identifier to create its IPv6 address. Avoiding 
duplicate addresses was the base justification for assigning the 
Modified EUI-64 identifier. [The authors say this configuration is out 
of scope, but this situation will likely happen in home use.]

Judging by the existing discussion on the WG, I don't think any of these 
problems are insoluble.

regards,
RayH

joel jaeggli wrote:
>> technical commentary on the draft and the working group's perception 
>> on its usefulness to its target audience.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Sep 2012 16:25:57 +0900

On Wed, Sep 5, 2012 at 2:24 PM, Ray Hunter <[email-masked]> wrote:

> [...]

Agreed. ND proxy is experimental, has problems, and isn't needed for the
use case that the draft cites it for. It should be removed from the draft.

> 4) Section 8.3.2 does not adequately deprecate single /64 working, which I
> consider harmful (as per BCP157).
>

I disagree that it's harmful; actually, I think it's very useful. It allows
a phone to offer IPv6 tethering without the carrier having to roll out a
release 10 network (and having to implement separate provisioning / billing
etc. for tethering). I agree that DHCPv6 PD is better, but in 3GPP networks
that's years away. To understand why, consider that that most advanced
carriers are just now rolling out LTE networks, and LTE is release 8.

That said, sharing a /64 is likely to happen whatever we do. So we have
three options:

   1. Say that /64 sharing shouldn't be done and watch as it happens anyway
   2. Say that if the CLAT wants to share the connection, it SHOULD use
   DHCPv6 PD, but if that's not available, then the CLAT MAY share a /64 (and
   potentially say how).
   3. Remain silent and punt to another document.

> Modified EUI-64 identifier via expert review (RFC5342 Section 5.1), in that
> the argumentation for assignment is very opaque, and the use-case is not
> completely defined e.g. the IID SHOULD NOT be used for L2 addressing by the
> CLAT.
>
> There is no detection or protection for cascaded CLATs, where if the IPv6
> address is assigned using the Modified EUI-64 identifier to a downstream
> CLAT, this will clash with the upstream CLAT if it has also used the
> Modified EUI-64 identifier to create its IPv6 address. Avoiding duplicate
> addresses was the base justification for assigning the Modified EUI-64
> identifier. [The authors say this configuration is out of scope, but this
> situation will likely happen in home use.]
>

Agreed. As is, I think the reserved IID should be removed from the document.

Remi's idea of allocating a /24 *block* of interface IDs and have the CLAT
avoid translation by mapping 10.0.0.0/8 addresses 1:1 into this reserved
black has promise, though. From a technical perspective it's a good
solution, but I don't know if IANA has a) has enough space to allocate a
whole /24 pr b) a process for doing so.

---

From: Rémi Després <[email-masked]>
Date: Wed, 5 Sep 2012 10:41:23 +0200

hi, Ray,

Good to see a synthetic comment on the draft.
more comments inline.

2012-09-05 07:24, Ray Hunter :

> Comments based on version 07 http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07
> 

Agreed.

> 2) The basic 464xlat architecture is sound and certainly worthy of advancement and further refinement.

Same view.

> Firstly ND Proxy is an experimental protocol, whereas the draft is aiming to become BCP.

+1

> Secondly, ND Proxy has inadequate loop detection, prevention and mitigation, for it to be reliably deployed in tethered networks consisting of multiple devices.  If 464XLAT is going to be effective, it will need to be incorporated into CPE devices. Section 4.1.3.3 of 4389 is a potential source of oscillation, instability, unpredictable behaviour, and provides a DoS vector, if 464XLAT were to be widely incorporated into consumer devices. [Authors claim multiple device working is out of scope, but this situation will likely happen in home use) ]
> 
> 4) Section 8.3.2 does not adequately deprecate single /64 working, which I consider harmful (as per BCP157).

- I see no reason why, if technically feasible (as is the case AFAIK), a node being delegated a /64 would be forbidden to use it on an IPv6 link, and simultaneously for private IPv4 using 464XLAT.

- BCP157 ?

> 5) Assignment of a single special-purpose IANA IID is problematic for 2 reasons.
> 
> I don't consider the document complies with the spirit of justifying the Modified EUI-64 identifier via expert review (RFC5342 Section 5.1), in that the argumentation for assignment is very opaque, and the use-case is not completely defined e.g. the IID SHOULD NOT be used for L2 addressing by the CLAT.

Pros and cons of CLAT reserved IID can be clarified as much as needed for experts to base their conclusions.

Actually, extending reservation to one IID range per RFC1918 private-IPv4 prefix permits a very substantial simplification of the draft. With it, the original spirit of a trivial combination of a stateless RFC 6145 in CLATs and stateful RFC 6146 in PLATs can be restored by: 
- suppressing the need for a variant with 464XLAT-specific IPv6 prefix, and one without
- suppressing the need for one variant without NAT44 and one with NAT44
- permitting safe operation in CLAT nodes that are delegated /64s 

Here is an example of what the simplified draft might look like if the approach is accepted. 

> There is no detection or protection for cascaded CLATs, where if the IPv6 address is assigned using the Modified EUI-64 identifier to a downstream CLAT, this will clash with the upstream CLAT if it has also used the Modified EUI-64 identifier to create its IPv6 address. Avoiding duplicate addresses was the base justification for assigning the Modified EUI-64 identifier. [The authors say this configuration is out of scope, but this situation will likely happen in home use.]

Authors aren't alone to note that CLATs won't be cascaded.:
- CLATs are IPv6-only upstream and "IPv6 + private IPv4" downstream (=> not cascadable)
- Trying to cascade would mean adding a PLAT function in a CLAT node, but this requires a public IPv4 range in the CLAT node, which is contrary to 464XLAT assumptions.

> Judging by the existing discussion on the WG, I don't think any of these problems are insoluble.

Agreed, but with apparently a different approach.

Regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Sep 2012 17:59:42 +0900

On Wed, Sep 5, 2012 at 5:41 PM, Rémi Després <[email-masked]>wrote:

> - Trying to cascade would mean adding a PLAT function in a CLAT node, but
> this requires a public IPv4 range in the CLAT node, which is contrary to
> 464XLAT assumptions.
>

A lot of things that shouldn't happen happen in real life. No matter what
you say, CLATs *will* be cascaded, because users will find ways to cascade
them. The only question is: "when (not if) two CLATs are cascaded, will
things still work"?

---

From: Rémi Després <[email-masked]>
Date: Wed, 5 Sep 2012 11:54:45 +0200

2012-09-05 10:59, Lorenzo Colitti :

> On Wed, Sep 5, 2012 at 5:41 PM, Rémi Després <[email-masked]> wrote:
> A lot of things that shouldn't happen happen in real life. No matter what you say, CLATs *will* be cascaded, because users will find ways to cascade them. The only question is: "when (not if) two CLATs are cascaded, will things still work"?

OK, fair enough.
I have to agree that ways to cascade CLATs can be found. This requires a IPv6-only router between the two cascaded CLATs, but is possible. 
Here is an example:

CLAT2--v6Link--v6onlyRouter--v4p&v6Link--CLAT1--v6Net--PLAT 

Such configurations can work with the CLAT-reserved IID ranges now proposed in http://www.ietf.org/mail-archive/web/v6ops/current/msg14077.html. For this, it suffices that the IPv6 prefix delegated to CLAT2 be other than CLAT1 extended with 0s. Thus IPv6 addresses of CLAT1 and CLAT2 are all different because they start with different prefixes.

This can be documented by saying, for example:
"In a CLAT site, prefix delegations to local nodes should be done only with prefixes that are not the site prefix followed by null bits. This is to permit IPv6-only subnets that may be configured in such sites to support CLAT nodes using the same PLAT as the site entrance CLAT."

Thoughts?
RD

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 5 Sep 2012 17:07:31 +0200

A handful of comments:

1. Section 5
It would be useful to indicate how this solution differs from MAP-T (
http://tools.ietf.org/html/draft-ietf-softwire-map-01 or
http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), as well
as to note the architectural underpinnings of NAT464 of the xlat solution
which it effectively validates.

In that context the points that IMO could help are:
- xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map allows
stateless or stateful NAT64)
- xlat focuses on deployments where client provisioning of the public IPv4
address is not possible or viable (map requires explicit provisioning, xlat
works on defaults)
- An alternative of the last point could be that the solution focuses on
deployments where the client does not require to be informed of the public
IPv4 address, and that default values are assumed.

2. Section 8.2.2
- It would help recasting this section as the "routed" clat mode. I.e the
clat is delegated a prefix for NAT64 usage, with this prefix being routed
i) by the clat device towards the upstream device ii) routed by and not
seen as directly connected by the upstream device.
- NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this should
be that NAT44 is used to map several IPv4s to one external IPv4.
- The figure reflects none of that; it shows 1:1 mapping between IPv4 and
IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is the
role of NAT44.
- It is not stated/specified what the external IPv4 address should be, or
how it is acquired/picked. This should be defined.
- What is currently also missing from this section is how the clat should
determine that it is to work in "routed" or "host" mode (section 8.3.2). It
is perfectly legitimate to have a PD and not use it for clat.

3. Section 8.3.2
- This section should be recast as xlat (clat) host mode for which the
upstream node considers the clat and the upstream device share an "on-link"
prefix.
- The ND-proxy appears NOT to be required on 3gpp, so it may be worthwhile
clarifying that.
- Personally I think that adding ND-proxy is undesirable (as also stated by
others) and harmful (eg for upstream devices such as BNGs). Devices on non
3gpp network should be directed to use the mode in section 8.3.2, which
would eliminate the need to mention proxy-ND at all.

Regards,
Woj.

On 2 September 2012 19:09, joel jaeggli <[email-masked]> wrote:

>> http://tools.ietf.org/html/**draft-ietf-v6ops-464xlat<http://tools.ietf.org/html/draft-ietf-v6ops-464xlat>
>> Please read it now. We are interested in, among other things, technical
>> commentary on the draft and the working group's perception on its
>> usefulness to its target audience.
>> ______________________________**_________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>>
>>
> ______________________________**_________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Ray Hunter <[email-masked]>
Date: Wed, 05 Sep 2012 18:16:32 +0200

I'd be very happy with your proposed option 2) Say that if the CLAT 
wants to share the connection, it SHOULD use DHCPv6 PD, but if that's 
not available, then the CLAT MAY share a /64 (and potentially say how).
> Lorenzo Colitti <mailto:[email-masked]>
> 5 September 2012 09:25
> On Wed, Sep 5, 2012 at 2:24 PM, Ray Hunter <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Agreed. ND proxy is experimental, has problems, and isn't needed for 
> the use case that the draft cites it for. It should be removed from 
> the draft.
>
>     4) Section 8.3.2 does not adequately deprecate single /64 working,
>     which I consider harmful (as per BCP157).
>
>
> I disagree that it's harmful; actually, I think it's very useful. It 
> allows a phone to offer IPv6 tethering without the carrier having to 
> roll out a release 10 network (and having to implement separate 
> provisioning / billing etc. for tethering). I agree that DHCPv6 PD is 
> better, but in 3GPP networks that's years away. To understand why, 
> consider that that most advanced carriers are just now rolling out LTE 
> networks, and LTE is release 8.
>
> That said, sharing a /64 is likely to happen whatever we do. So we 
> have three options:
>
>     DHCPv6 PD, but if that's not available, then the CLAT MAY share a
>     /64 (and potentially say how).
>     I don't consider the document complies with the spirit of
>     justifying the Modified EUI-64 identifier via expert review
>     (RFC5342 Section 5.1), in that the argumentation for assignment is
>     very opaque, and the use-case is not completely defined e.g. the
>     IID SHOULD NOT be used for L2 addressing by the CLAT.
>
>     There is no detection or protection for cascaded CLATs, where if
>     the IPv6 address is assigned using the Modified EUI-64 identifier
>     to a downstream CLAT, this will clash with the upstream CLAT if it
>     has also used the Modified EUI-64 identifier to create its IPv6
>     address. Avoiding duplicate addresses was the base justification
>     for assigning the Modified EUI-64 identifier. [The authors say
>     this configuration is out of scope, but this situation will likely
>     happen in home use.]
>
>
> Remi's idea of allocating a /24 *block* of interface IDs and have the 
> CLAT avoid translation by mapping 10.0.0.0/8 <http://10.0.0.0/8> 
> addresses 1:1 into this reserved black has promise, though. From a 
> technical perspective it's a good solution, but I don't know if IANA 
> has a) has enough space to allocate a whole /24 pr b) a process for 
> doing so.
> Ray Hunter <mailto:[email-masked]>
> 5 September 2012 07:24
> consisting of multiple devices.  If 464XLAT is going to be effective, 
> it will need to be incorporated into CPE devices. Section 4.1.3.3 of 
> 4389 is a potential source of oscillation, instability, unpredictable 
> 4) Section 8.3.2 does not adequately deprecate single /64 working, 
> which I consider harmful (as per BCP157).
>
> I don't consider the document complies with the spirit of justifying 
> the Modified EUI-64 identifier via expert review (RFC5342 Section 
> 5.1), in that the argumentation for assignment is very opaque, and the 
> use-case is not completely defined e.g. the IID SHOULD NOT be used for 
> L2 addressing by the CLAT.
>
> used the Modified EUI-64 identifier to create its IPv6 address. 
> Avoiding duplicate addresses was the base justification for assigning 
> the Modified EUI-64 identifier. [The authors say this configuration is 
> out of scope, but this situation will likely happen in home use.]
>
> ------------------------------------------------------------------------

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 5 Sep 2012 18:31:54 +0000

> The current discussions on ND proxy and/or IANA-reserved IIDs is still progressing, but AFAIK without clear conclusion.

<chair>
The purpose of a WGLC is, as you say, to ensure that important concerns have not been missed or misunderstood. It is not to to prove or create unanimity of viewpoint, although that would be a happy outcome. If in the opinion of the chairs all opinions have been expressed and new issues are not being raised, a single person or small group that disagrees with the outcome is consistent with "rough consensus".

I note that this morning we have additional comments from Ray and Woj, which I think need to be heard and addressed. So I'll let the WGLC continue the remainder of this week to see what additionally shakes loose. Note to the authors: we will need a -08 as an outcome of the WGLC.
</chair>

<contributor>
Let me see if I can tease apart the issue of an IID, ND Proxy, and DHCP-PD a bit. I have a view, which I will state, but as a contributor I'm not trying to impose my view as much as put the arguments all in one place and try to tease out a resolution. If this helps, it helps, and if it doesn't, forget I said it.

The purpose of an IID (or an Endpoint ID, which would be an IID used on all interfaces) is to uniquely identify an interface (or system) within a local domain below the Internet Layer. RFC 4291 describes how one might derive it from an EUI-48 or EUI-64 number; RFC 3972 describes another mechanism based on cryptography, RFC 4941 describes a mechanism that uses a random number generator, RFC 4291 and 6052 describe approaches derivative from IPv4 addresses, and there is always the possibility of manual assignment. In no case, as far as I am aware, does one start from the IID and generate a lower layer address from it; the lower layer address, if it is used at all, is only used as input to the IID generation algorithm. Regardless of the way the IID is formed, it has some possibility of being a duplicate address, and the wise implementation will take the time to verify its uniqueness. Since there are so many ways an IID can be created, I personally find little use in mandating anything specific about it unless there is an interoperability requirement in a specific implementation, such as exists in SEND.

So the entire debate about an IANA-specified IID is, frankly, lost on me. I have difficulty formulating the argument. It is, by any other description, a more-or-less-random 64 bit number, and the only use of it once it is created is as a search key in the neighbor table.

Regardless of how the IID is formed, there is a question of how the network is formed. If we define a local network to include one or more router interfaces connected to a set of clients over some form of media, there are two broad classes of media - ones in which all clients communicate directly with each other at the Internet Layer (such as in an Ethernet, switched or otherwise), and ones in which they communicate at the IP layer though an intermediate device (such as a BRAS or CMTS). Neighbor Discovery is designed for the Broadcast Multi-access case, and ND Proxy is designed for the Non-Broadcast Multi-access case. In both cases, IPv6 and Neighbor Discovery (direct or proxy) assume that, from the perspective of any given interface in that local network, the local network operates as a simple star or multi-star - traffic sent from one interface to another in the local network travels in sequence, may be lost en route, and apart from loss is conveyed in a reasonably predictable fashion.

It is possible for the client device to act as a switch or repeater to other devices beyond it; analytically, the device might be viewed as incorporating a switch for which the device is itself one of the clients. In this case, the cascaded devices beyond it appear to be on the same local network as the client itself. From an IP perspective, one would expect it to use the same subnet prefix and require the use of ND or ND Proxy just as the client itself does.

The other view of the device is that it operates, for cascaded devices, not as a switch but as a router. In this case, it needs a prefix assigned to it for the cascaded LAN or LANs, and DHCP-PD is a reasonable means for doing so.

So to me, the question of ND Proxy vs DHCP-PD comes down to the intended structure of the network and the services it offers. If the structure of the service provider's access network is non-broadcast multi-access, which I understand wireless networks such as 3G/4G and LTE to be, then it either requires the use of an ND Proxy or it must assign its client's addresses, in the interest of uniqueness - and DHCPv6 would still require DAD of the link-local address, which implies ND Proxy. If the service provides no capability for cascading client networks, then the model of masquerade of an incorporated switch, or stateful IPv6/IPv6 translation, is required to work around the limitations of the service provider's service. If the service provider is offering a service of connecting client networks - for which homenet becomes directly applicable - then DHCP-PD and some form of routing infrastructure (at least dynamic static routing) becomes preferable for manageability reasons.

Following that line of reasoning, I might suggest that the document describe the non-broadcast multi-access nature of the service provider access network and require the implementation of ND Proxy within it, which I think it already does. It might go on to describe the nature of the client networks it expects, offering three cases - no cascaded devices (the service is to a contracted instrument), a mobile hot spot (a small number of cascaded devices treated as part of the service provider access network and uses the client instrument as a switch), or a cascaded network (which uses the client instrument as a router, which in turn implies the use of DHCP-PD). 

If that were done, would the proponents of the various views consider their viewpoints adequately addressed?

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 5 Sep 2012 12:56:28 -0700

> If that were done, would the proponents of the various views consider their viewpoints adequately addressed?

IMHO, trying to define how to construct IPv6 access networks sharing a
/64 is out of scope for 464XLAT.  As part of the inventing the 464XLAT
service and how we could specify it from the ground up, we found it
required to speak to ND proxy, Remi's reserved IID solutions, and
others ... coming from 10,000 meters up and going back down to RFC
level, at this point... i do not believe we need to specify these
methods of extending a /64 or reserving IANA resources.  Remi's and
others ideas have been clever, and i believe they can be re-spun as
more generic contributions to v6ops or HOMENET

My hope is that the -08 can reach rough consensus by just saying that
the CLAT SHOULD do DHCP-PD to acquire a /64 to be used exclusively for
stateless translation.  If DHCP-PD is not available, the CLAT MAY
share the WAN /64 to the LAN in an appropriate way that does not cause
address conflicts or loops.  I believe this is the direction that Ray
and Lorenzo have said they support.

And just leave it at that.

Today, /64 is shared between WAN and LAN in many ways, some are IETF
specified (ND Proxy) and some are not such as behaving as
Switch/Router.  In the case of the Android CLAT code that was
submitted to AOSP, the /64 is simply copied from the WAN 3G/4G
interfaces to the LAN. No magic. No ND Proxy. No DHCP.  But, it works
for all known cases.

464XLAT, as stated in the introduction, is just combining stateless
and stateful protocol translation to overcome some gaps that inhibit
wider IPv6 adoption and IPv4 sunsetting.  It is not anything else.

CB

---

From: Maoke <[email-masked]>
Date: Thu, 6 Sep 2012 10:56:57 +0900

hi Woj,

+1 on your comment 1.
2012/9/6 Wojciech Dec <[email-masked]>

> http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), as
> well as to note the architectural underpinnings of NAT464 of the xlat
> solution which it effectively validates.
>

> IPv4 address, and that default values are assumed.

i am not sure but have another observation: 464xlat, using existing
mechanism of RFC6145/6146 and address format of RFC6052, is used in within
the same address planning autonomous system with the same prefix for the
RFC6052 usage; while MAP can work in a "MAP domain" across over different
prefixes even belonging to different autonomous systems with the cost of
distributing rules among involved nodes.

- maoke

> - Personally I think that adding ND-proxy is undesirable (as also stated
> by others) and harmful (eg for upstream devices such as BNGs). Devices on
> non 3gpp network should be directed to use the mode in section 8.3.2, which

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 5 Sep 2012 19:43:16 -0700

Woj,

On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec <[email-masked]> wrote:
> A handful of comments:
>
> 1. Section 5
> It would be useful to indicate how this solution differs from MAP-T
> (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or

No, we will not be casting 464XLAT in light of other solutions.  The
WG, AFAIK, concluded this here
http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html

And, AFAIK, MAP-T  is not longer an actively pursued solution.  A coin
was flipped, and the IETF moved on.

> stateless or stateful NAT64)

MAP allows stateful sharing of public IPv4 addresses on NAT64?  I am
not sure how that can be given that Softwires does not have a charter
for stateful solutions.  And, AFAIK, the current MAP document does not
reflect any stateful work for sharing public IPv4 addresses.  Doing a
search on draft-ietf-softwire-map-02 shows no references to RFC 6145
and RFC 6146, which are the core of 464XLAT.

> address is not possible or viable (map requires explicit provisioning, xlat

Yes.

i don't follow the rest of the comments and imagine the discussion
will shift after we release -08 where perhaps these details are
purposefully not specified and left to implementation discretion.

CB

> clat is delegated a prefix for NAT64 usage, with this prefix being routed i)
> by the clat device towards the upstream device ii) routed by and not seen as
> directly connected by the upstream device.
>>> commentary on the draft and the working group's perception on its usefulness
>>> to its target audience.

---

From: Maoke <[email-masked]>
Date: Thu, 6 Sep 2012 13:04:45 +0900

Cameron,
2012/9/6 Cameron Byrne <[email-masked]>

> well

> was flipped, and the IETF moved on.

i agree that 464xlat document doesn't need to compare with any other
solutions. however, i guess you also support Woj's effort of sharing the
understanding. and AFAIK, MAP-T, will be still the softwire WG document
even the status might be experimental. further, in the MAP deployment draft
that i am participating, we are obliged to include the understandings in
order that the operators reading the deployment guidance may get a clear
big picture of the relationship among all the stuffs in the solution space.

i would like to share another point: maybe some people think the about one
year effort of making MAP-T and -E a unified work is vain, maybe some think
we should to do the coin toss one year ago, i don't agree. the effort of
unification made out a common address mapping algorithm and the unified
format, enabling operators change their mode of transport once they
understand somewhere the double translation, compatible with single
translation, is needed in their system architecture.

such an understanding on the necessity of translation, AFAIK, is also
significant to those who would like to deploy 464xlat. ;-)

- maoke

> by

---

From: Ray Hunter <[email-masked]>
Date: Thu, 06 Sep 2012 07:30:05 +0200

Agreed.

Cameron Byrne wrote:
> <snip>My hope is that the -08 can reach rough consensus by just saying 
> that the CLAT SHOULD do DHCP-PD to acquire a /64 to be used 
> exclusively for stateless translation. If DHCP-PD is not available, 
> the CLAT MAY share the WAN /64 to the LAN in an appropriate way that 
> does not cause address conflicts or loops. I believe this is the 
> direction that Ray and Lorenzo have said they support. And just leave 
> it at that. Today, /64 is shared between WAN and LAN in many ways, 
> some are IETF specified (ND Proxy) and some are not such as behaving 
> as Switch/Router. In the case of the Android CLAT code that was 
> for all known cases. 464XLAT, as stated in the introduction, is just 
> combining stateless and stateful protocol translation to overcome some 
> gaps that inhibit wider IPv6 adoption and IPv4 sunsetting. It is not 
> anything else. CB<snip>

---

From: Maoke <[email-masked]>
Date: Thu, 6 Sep 2012 15:09:46 +0900

hi authors and all,

i have objection on the statement that traffic flow of CLAT to CLAT
communication is out of scope. an operator may deploy a domain with the
address planning for the private addresses and surely in such a case CLAT
to CLAT communication (mesh mode) is a natural result of the 464xlat. i
don't think it is needed to exclude this usage from the document. when
using private (static) addresses for in-domain servers, such a feature is
very useful. stating that 464xlat focusing on hub&spokes leaves an
uncertainty: once the CLAT to CLAT communication is needed, what is the
wanted behavior: A) immediately deliver to the peer CLAT; B) hairpinning
via PLAT?

- maoke

2012/8/22 Fred Baker (fred) <[email-masked]>

> I should note that the current thread has a subject line reading -06.txt,
> but the current version is -07.txt. You may find the diffs (fairly
> extensive) at
>
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-07.txt
>
>
> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote:
>
> ----------------------------------------------------
> The ignorance of how to use new knowledge stockpiles exponentially.
>    - Marshall McLuhan
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Sep 2012 15:20:12 +0900

> more generic contributions to v6ops or HOMENET

Saying "sharing a /64 with downstream devices is out of scope" is a
perfectly valid position to take. However, if we decide to say that, then
for consistency, we should probably also say "sharing an IPv4 address with
downstream devices is out of scope". As you say, making these two
statements and leaving address sharing to a future document would be a good
way to remove all current disagreements and move ahead.

However, even if we take that approach, we still have to decide *something*
in this document. Specifically, we need to decide what IID the CLAT will
use when sending its own packets - because that will have impact on how the
/64 is shared in the future. So in some sense, we still need to decide
something now.

> address conflicts or loops.

I'm not one of the chairs, but it seems to me that given recent comments on
the text of the draft, think you'll need a respin anyway.

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Sep 2012 09:20:43 +0200

2012-09-05 21:56, Cameron Byrne :
...
> interfaces to the LAN. No magic. No ND Proxy. No DHCP.  But, it works

Following recent technical discussions, let's focus on this /64 WAN-prefix case, the only one that IMHO still needs a refinement in the draft.

Let's assume IANA has reserved for CLATs the following subranges of the range available for allocation in RFC5342 section 2.2.2:   
 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8
 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12
 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16
Then, SIMPLY by using in CLATs RFC6052 addresses whose /96 has 0x02005E10 after the /64:
- No NAT44 is necessary ( CLATs are completely stateless, the originally objective of 464XLAT).
- No conflict can exist between any of the IPv4-embedded addresses used by CLATs and any host address that has a standard-compliant IID (RFC 6052). This is completely independent from what is done (or not done) if a WAN address using the /64 is configured at the CLAT WAN interface.  

=> It would be A PITY to miss this operational improvement of the BCP (and its simplification by eliminating its NAT44 variant) if reasons for that would be refusal to take the time to understand the subject, and/or the unjustified belief that getting IANA to accept an IETF reservation request would be difficult. 

It can be checked with Dan Drown that the above is understandable by an implementor.

Best regards,  
RD

---

From: Maoke <[email-masked]>
Date: Thu, 6 Sep 2012 16:21:20 +0900

another objection is, Section 9 states "another,
   if combined with BIH [RFC6535 <http://tools.ietf.org/html/rfc6535>], is
a IPv4 -> IPv6 translation for
   reaching IPv6-only servers from IPv4-only clients that can not
   support IPv6. "

it sounds to me that 464xlat does suggest to apply BIH, as part of the best
practice, for IPv4 client reaching IPv6-only servers. to my understanding,
there could be several alternative ways to achieve that, why we should be
bounded with BIH?

sorry i didn't catch the discussion on this issue before.

- maoke

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Sep 2012 16:48:32 +0900

On Thu, Sep 6, 2012 at 4:20 PM, Rémi Després <[email-masked]>wrote:

> Let's assume IANA has reserved for CLATs the following subranges of the
> range available for allocation in RFC5342 section 2.2.2:

Since assuming the impossible leads to failure, we first need to ensure
that:

   1. IANA has the authority to assign such address space.
   2. IANA is willing to assign such address space
   3. IANA has the techical capability (e.g., processes) to assign such
   address space.

Without answers to the above questions, we cannot proceed. Remi, do you
know the answers?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Sep 2012 16:50:32 +0900

On Thu, Sep 6, 2012 at 4:21 PM, Maoke <[email-masked]> wrote:

>    if combined with BIH [RFC6535 <http://tools.ietf.org/html/rfc6535>],
> is a IPv4 -> IPv6 translation for
> it sounds to me that 464xlat does suggest to apply BIH, as part of the
> best practice, for IPv4 client reaching IPv6-only servers. to my
> understanding, there could be several alternative ways to achieve that, why
> we should be bounded with BIH?
>

IIRC, that text was added to an earlier version to appease Remi, who was
demanding it. I agree that it is superfluous to make that statement in this
draft.

---

From: Maoke <[email-masked]>
Date: Thu, 6 Sep 2012 16:54:16 +0900

2012/9/6 Lorenzo Colitti <[email-masked]>

>    4.
how can we ensure the above addresses do not conflict with any manually,
arbitrarily configured addresses? i am lost. :P - maoke

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Sep 2012 10:01:52 +0200

Le 2012-09-06 à 09:48, Lorenzo Colitti a écrit :

> On Thu, Sep 6, 2012 at 4:20 PM, Rémi Després <[email-masked]> wrote:
> Since assuming the impossible leads to failure, we first need to ensure that:
> IANA has the authority to assign such address space.
> IANA is willing to assign such address space
> IANA has the techical capability (e.g., processes) to assign such address space.
> Without answers to the above questions, we cannot proceed. Remi, do you know the answers?

AFGAIK, IANA is responsible to maintain registries of number that need to be assigned for IETF RFCs.
Copy added to Ron who has more experience on this.

RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Sep 2012 17:02:44 +0900

> arbitrarily configured addresses? i am lost. :P - maoke

AIUI, we say "conflicts are impossible, because this is a reserved range",
and then we cross our fingers.

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Sep 2012 10:06:17 +0200

Le 2012-09-06 à 09:50, Lorenzo Colitti a écrit :

>    if combined with BIH [RFC6535], is a IPv4 -> IPv6 translation for
> it sounds to me that 464xlat does suggest to apply BIH, as part of the best practice, for IPv4 client reaching IPv6-only servers. to my understanding, there could be several alternative ways to achieve that, why we should be bounded with BIH?
>  
> IIRC, that text was added to an earlier version to appease Remi, who was demanding it. I agree that it is superfluous to make that statement in this draft.

I didn't ask for this statement in particular, just to remove a statement that suggested that 464XLAT would permit IPv4 applications to reach IPv6-only servers (which happens to be in scope for BIH, not in that of 464XLAT)
Deleting this sentence is perfectly fine with me.

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Sep 2012 10:21:27 +0200

> The purpose of a WGLC is, as you say, to ensure that important concerns have not been missed or misunderstood. It is not to to prove or create unanimity of viewpoint, although that would be a happy…

At this stage, there is still AFAIK an important "concern that has been misunderstood": how to deal safely and simply with /64 delegated prefixes.   
Refs.:
- www.ietf.org/mail-archive/web/v6ops/current/msg14093.html
- (*) below. 

> The purpose of an IID (or an Endpoint ID, which would be an IID used on all interfaces) is to uniquely identify an interface (or system) within a local domain below the Internet Layer. RFC 4291 des…

Same understanding.

> So the entire debate about an IANA-specified IID is, frankly, lost on me. I have difficulty formulating the argument. It is, by any other description, a more-or-less-random 64 bit number, and the o…

(*)
That's the point where AFAIK progress continues to be made to reach common understanding.
I may be wrong but I think that:
- Dan Drown, who has implemented a CLAT, does understand how the proposed solution works.
- Lorenzo has seen its potential. (ref. the end of www.ietf.org/mail-archive/web/v6ops/current/msg14073.html). He still fears that reserving IID sub-ranges in a range that remains available in RFC 5342 section 2.2.2 might be difficult, but this isn't AFAIK the case. 

> Regardless of how the IID is formed, there is a question of how the network is formed. If we define a local network to include one or more router interfaces connected to a set of clients over some…

Same understanding.

> The other view of the device is that it operates, for cascaded devices, not as a switch but as a router. In this case, it needs a prefix assigned to it for the cascaded LAN or LANs, and DHCP-PD is…

No cascading issue in the /64 case. 

> If that were done, would the proponents of the various views consider their viewpoints adequately addressed?

This would NOT be enough for the /64 issue to be be "adequately addressed" (IMHO). 

Regards,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 6 Sep 2012 10:38:27 +0200

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

 I didn't say that the xlat draft has to describe the MAP, what I did
propose are listing points that make the xlat solution unique. It is a
reasonable expectation of a draft from an SDO to at least contextualise to
the reader as to how it relates to other drafts from that same SDO. This is
very much in line with the conclusion in the mail you reference. At the
moment the draft does not clarify that.

> was flipped, and the IETF moved on.

That is not correct. MAP-T remains an active Softwires WG draft, albeit
with experimental status which is not definitive.
The coin flip, was about one-draft or two drafts, not about MAP-T being
"abandoned"

> and RFC 6146, which are the core of 464XLAT.

map draft-02 is the "post coin flip" version for MAP-E. The equivalent
MAP-T draft is being readied and we'll post it soon, but it will be as per
http://tools.ietf.org/html/draft-ietf-softwire-map-01 where you will find
abundant references to 6145.
We have been here before. MAP and XLAT are both NAT464 architectures. A MAP
CEs jsut like a clat has proven interoperability with a regular stateful
NAT64 core element. The difference is that the MAP CE requires explicit
provisioning.

> purposefully not specified and left to implementation discretion.

AFAIK the WG last call is for draft-08, not for some draft that has yet to
be written.
The comments below, which I kindly ask that they be addressed, focus on the
key aspect of whether the clat operates on a host or routed mode. The draft
currently confuses this as operating with NAT44 or without, which is
totally orthogonal. And no, in my opinion it cannot be left to an
implementation to decide whether to use this mode or another, as it
directly leads to the choices of ND_proxy, etc.

-Woj.

---

From: GangChen <[email-masked]>
Date: Thu, 6 Sep 2012 17:47:42 +0800

> sorry i didn't catch the discussion on this issue before.

There was a quite long discussion,
since you didn't follow that, I list the links below for your convenience.

"A way forward for 464XLAT", started with
http://www.ietf.org/mail-archive/web/v6ops/current/msg12521.html
"A way forward for 464XLAT - using BIH", started with
http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html
"I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with
http://www.ietf.org/mail-archive/web/v6ops/current/msg12628.html
" [v6ops] draft-ietf-v6ops-464xlat - which status?"started with
http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html
....

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

BRs

Gang

---

From: Maoke <[email-masked]>
Date: Thu, 6 Sep 2012 20:04:34 +0900

hi Gang,

thanks for the links!

1. i don't think an early conclusion of the authors cannot be objected and
thought over again, before the last call is closed.

2. i don't think it is a loss to state out of scope (or not to mention that
at all) for IPv4-only app access to IPv6-only server. this could be
achieved by simply configuring the IPv6-only server with an RFC6052
IPv4-translatable address and relying CLAT RFC6145 translation, or by a
NAT64 located anywhere between the IPv4 app and the IPv6 domain implemented
in anyway not necessarily the socket layer solution, even though BIH does
possibly work, by a proxy (ALG), etc.

3. i don't think the author has tested the BIH with CLAT for an IPv6-only
server, at least i have not seen any discussion/report from the authors or
WG members about the test. to my understanding, the BIH/CLAT work here is
not yet practiced. why we need/should put a stuff not yet practiced into a
BCP??

(NOTE, the test result from you only illustrates that BIH itself is
working, not the BIH/464xlat with IPv4-only app access to IPv6-only server.
the tested applications, skype, MSN, etc. are none of business of the
so-called IPv6-only servers).
4. i was even confused by the text "By combining 464XLAT with BIH
[RFC6535], it is also possible to provide single IPv4/IPv6 translation
service" itself. BIH has done the single IPv4/IPv6 translation right? what
is the significance of such a "combination"? what is the add-on?

integrating the compressor, condenser, expansion valve, evaporator into a
fridge is an innovation (as the authors did for the 464xlat) but we cannot
call a "fridge + microwave oven put on the top of the fridge" a new
"architecture" of better practice.

- maoke

2012/9/6 GangChen <[email-masked]>

> best
> technical

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 6 Sep 2012 06:16:39 -0700

>
>
> AIUI, we say "conflicts are impossible, because this is a reserved
range", and then we cross our fingers.

I agree with Lorenzo's sarcasm.

That said, we have been pushing this draft for a year trying to drive
concensus. If we do not limit the scope to the core objective we will be
here for another year while the issue of ipv4-only hosts and apps delays
and hinders broader ipv6 deployment.

CB

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 6 Sep 2012 06:26:30 -0700

well

This was included before and has beeen removed because those words were not
timeless or essential to a standards doc. That was thd WG feedback.

"abandoned"
> We have been here before. MAP and XLAT are both NAT464 architectures. A
MAP CEs jsut like a clat has proven interoperability with a regular
stateful NAT64 core element. The difference is that the MAP CE requires
explicit provisioning.

We have been here before, as you noted. If you want text, suggest it. You
know the difference between the 2, no?

CB
> AFAIK the WG last call is for draft-08, not for some draft that has yet
to be written.
> The comments below, which I kindly ask that they be addressed, focus on
the key aspect of whether the clat operates on a host or routed mode. The
draft currently confuses this as operating with NAT44 or without, which is
totally orthogonal. And no, in my opinion it cannot be left to an
implementation to decide whether to use this mode or another, as it
directly leads to the choices of ND_proxy, etc.
technical
>> >>> commentary on the draft and the working group's perception on its
usefulness

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 6 Sep 2012 15:47:28 +0200

On 6 September 2012 15:26, Cameron Byrne <[email-masked]> wrote:

> This was included before and has beeen removed because those words were
> not timeless or essential to a standards doc. That was thd WG feedback.
>
What was included? Certainly NOT the points i suggested.
If you're seeking for words that are timeless, then I think that the whole
of section 5, entitled "Motivation and Uniqueness" can be deleted.

Overall, it may help if you actually took on board constructive feedback.
The points I proposed indicate what is unique in xlat solution.

> know the difference between the 2, no?

Reposting the suggested text & changes:
Section 5
- xlat adopts/assumes exclusively a stateful NAT64 PLAT core
- xlat focuses on deployments where client provisioning of the public IPv4
address is not possible or viable
- An alternative of the last point could be that the solution focuses on
deployments where the client does not require to be informed of the public
IPv4 address, and that default values are assumed.

2. Section 8.2.2

3. Section 8.3.2

-Woj.

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Sep 2012 16:22:59 +0200

2012-09-06 15:16, Cameron Byrne :
> >> how can we ensure the above addresses do not conflict with any manually, arbitrarily configured addresses? i am lost. :P - maoke 
> >
> >
> > AIUI, we say "conflicts are impossible, because this is a reserved range", and then we cross our fingers.
> >
> 
This "sarcasm" isn't deserved: one who manually configures a host with an invalid address with regard to RFC 4291 should cross his fingers in all cases, with 464XLAT or not.

Besides, it is particularly unexpected from you, after you stated "In the case of the Android CLAT code that was submitted to AOSP, the /64 is simply copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND Proxy. No DHCP.  But, it works for all known cases".
With this, collisions between CLATs and host addresses are possible even with well-behaved hosts => The need to cross fingers is permanent ;-).
By using the proposed IANA-EUI-64 based /96, this is avoided and, with a MAY in the draft, the somewhat risky choice you have described remains possible.

> That said, we have been pushing this draft for a year trying to drive concensus. If we do not limit the scope to the core objective we will be here for another year while the issue of ipv4-only hosts and apps delays and hinders broader ipv6 deployment.
> 
On this, we agree.

Still convinced to be one of the best supporters of a good 464XLAT without undue delay,
Best regards,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 6 Sep 2012 16:51:42 +0200

Just skip on shared prefix support in host mode. It's not needed for 3gpp
usage.
On other segments point to the PD/routed mode.

No need of IANA special codes or ND-Proxy/whatever.

-Woj.

On 6 September 2012 15:16, Cameron Byrne <[email-masked]> wrote:

> >> how can we ensure the above addresses do not conflict with any
> manually, arbitrarily configured addresses? i am lost. :P - maoke
> >
> >

---

From: GangChen <[email-masked]>
Date: Thu, 6 Sep 2012 22:52:07 +0800

> thought over again, before the last call is closed.

Sure. If you do think several-months lasted discussion doesn't
convince and would like to boil the ocean, we could re-open it.
But please read the conversion happened before on the list to ensure
new discussion is not backward.

> at all) for IPv4-only app access to IPv6-only server.

(*)Those arguments were discussed in the thread of "A way forward for
464XLAT - using BIH".
The loss and gain have been well identified. The point is adding BIH
only can be complementary to 464xlat scenario, no harm.
If you have further point, please identify.

> this could be
> IPv4-translatable address and relying CLAT RFC6145 translation,

1) The IPv4-Embedded IPv6 address on CLAT is inserted with IPv4
private address.
When the two IPv4-embedded IPv6 addresses with conflicted IPv4 address
talk to an IPv4-translatable IPv6 address, it would be failed since
IPv6-only server is confused that outgoing packages should send to
which CLAT.
2) IPv6-only server with IPv4-translatable address would cause one
public IPv4 address.
Most people do IPv6 because IPv4 is limited, so doing this way does
not really buy you anything.
3) There no RFC stated the solution what you called as RFC6052+RFC6145;
whether that is a doable way need to be further justified.  But BIH is
a standard track

> or by a

I don't get it. If there is NAT64, there is nothing to do with the
scenario you are talking about.

> possibly work, by a proxy (ALG), etc.

Please note RFC6535 has two flavors, i.e. header translation and
socket translation. It’s really not necessarily the socket layer
solution.

> WG members about the test.

(**)I guess you will see the report soon, because we are coding that right now.
At this stage, what I can tell is most parts are same in the combining code.

> to my understanding, the BIH/CLAT work here is

Please don't do the arbitrary objection even you didn't evaluate it.
It is a strange logic.
"I don't do that. I even don't know that. So I think that is not practiced."
That is an unfair argument.

> so-called IPv6-only servers).

Please see the (**) and carefully read my report
http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html
The shared experiences are in 464 contexts.
With 464xlat, we could easily do *combining 464XLAT with BIH*.
It's of significance.

> is the significance of such a "combination"? what is the add-on?

Same comment with (*). If you have concrete point, please identify.
Ambiguous arguments and arbitrary objections only can waste our energy
and time. It doesn't help the document imho.

> "architecture" of better practice.

I didn't fully get your point. 464xlat is not a fridge actually :)
Again, please directly identify your technical points/concerns.

BRs

Gang

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Sep 2012 00:15:34 +0900

> Again, please directly identify your technical points/concerns.

I think the comment was intended to mean:

2. BIH is not necessary for the operation of 464xlat, so it doesn't have to
be in the draft.

3. The scenario that BIH is intended to solve is further in the future and
we do not yet have as much operational experience with it. So it should not
go into a BCP for 464xlat, which is a different transition mechanism.

4. Saying "you can use BIH with 464xlat" is not very useful by itself
because 464xlat doesn't work together with BIH in any special way. It only
provides connectivity. Yes, you can do BIH with 464xlat. But you can also
do it with DS-Lite, or 6rd, or native dual-stack. Saying "you can use BIH
with 464xlat" is like saying "you can run HTTP over TCP": it's true, but it
doesn't need to go into the TCP RFC.

For what it's worth, I agree.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 6 Sep 2012 08:27:31 -0700

Rémi ,

On Thu, Sep 6, 2012 at 7:22 AM, Rémi Després <[email-masked]> wrote:
> This "sarcasm" isn't deserved: one who manually configures a host with an
> invalid address with regard to RFC 4291 should cross his fingers in all
> cases, with 464XLAT or not.
>

Here are the facts as i see them:

1.  Many people on the list, including me, say we must share a /64
from WAN to LAN

2.  Multiple real world implementations of this /64 sharing exists in
various types of nodes, including the AOSP Android code.  Hermant also
references he has experience with some CPE that share a /64 in
production networks using ND Proxy. And there is also the case of a
CPE that simply bridges WAN to LAN and has a logical / virtual place
on that share /64.  Lorenzo also specified a method here
http://www.ietf.org/mail-archive/web/v6ops/current/msg13977.html

3.  There is no standards track way to share a /64 from WAN to LAN,
the party line is DHCP-PD is the solution.  New protocol work happens
in 6MAN.

4.  Remi has provided, what i consider, to be a workable solution that
avoids the case of NAT44.

So, we have a problem since #1 and #3 are a challenge, and #2 exists

#4 is workable, but it has opponents and requires "hard coding" and
really is not core to 464XLAT.  Removing the need for NAT44 is not a
goal, the overhead of having NAT44 is inconsequential to a modern CPE,
including smartphones.  Related to hard coding, there is no RFC1918
address that we can pick.  ISPs are now dictating how residential LANs
must be configured so they do not overlap with the SP network's use of
RFC1918 space ...
http://keithbartholomew.com/2012/04/how-att-u-verse-broke-my-home-network/

> Besides, it is particularly unexpected from you, after you stated "In the
> case of the Android CLAT code that was submitted to AOSP, the /64 is simply
> copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND Proxy. No
> DHCP.  But, it works for all known cases".
> With this, collisions between CLATs and host addresses are possible even
> with well-behaved hosts => The need to cross fingers is permanent ;-).

No, NDP/DAD runs normally on the LAN side as a /64 and the WAN side is
a /128 ...  /128 on WAN is normal operations for a Android phone on a
3GPP network.

The main takeaway from this:  implementation specific solutions are ok
and left to the implementer and network operator to consider pros and
cons.

The party line remains:  DHCP-PD is best!  While reality dictates and
the 464XLAT I-D must reflect  that /64 sharing exists.

I am not confident that this group of folks who don't have a very good
understanding of probability (manually configures 64 bit collisions?!)
 will come to a consensus on a general solution, and even if they can
come to a consensus, 464XLAT is not the right vehicle for specifying
how a /64 is shared across interfaces.

Let us just say /64 sharing exists and move on.  If we believe /64
must be codified on standards track, 6MAN may be the place for that
with its own I-D.

> By using the proposed IANA-EUI-64 based /96, this is avoided and, with a MAY
> in the draft, the somewhat risky choice you have described remains possible.
>
> here for another year while the issue of ipv4-only hosts and apps delays and
> hinders broader ipv6 deployment.
>
> On this, we agree.
>

Thanks again!

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Sep 2012 17:43:24 +0200

> must be codified on standards track, 6MAN may be the place for that

It seems to me, we should agree that:
(a) How to share a /64 between WAN and LAN IS NOT a 464XLAT issue (your detailed point above).
(b) What remains a 464XLAT issue is to ensure that, whatever the chosen solution for (a), 464XLAT can avoid to interfere with it. That's what is achieved with the proposed reservation of three currently unused IID-ranges, and the well-chosen /96 in CLAT addresses.

RD

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 00:22:57 +0800

> 2. BIH is not necessary for the operation of 464xlat, so it doesn't have to

464xlat is intended to support IPv4-only capable application.
There is no limitation CLAT only can communicate with IPv4 server in the wild.
Missing BIH is incomplete when communication with IPv6 is needed.

> go into a BCP for 464xlat, which is a different transition mechanism.

RFC6535 does exist on standard track. It's already approved it got
significant community reviews and appears to enjoy enough community
interest according to RFC2026. It's qualified to go into a BCP. More
operational experiences are always needed for any technologies at any
time. It should not be an obstacle to be adopted in a proper scenario.
464XLAT purpose is to facilitate deployments and use of IPv6-only
networks. It does this better if combined there is BIH in CLAT nodes.
It's indeed in the same building block

> because 464xlat doesn't work together with BIH in any special way.

Supporting IPv4-only application is the same goal, under which 464xlat
surely should work with BIH.

> It only
> do it with DS-Lite, or 6rd, or native dual-stack.

You can't. The requirements doing encapsulation and translation are
likely exclusive. I don't think DS-lite and BIH could stay together
from an operational point of view. 6rd even has reversed scenario,
i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but
scenario of BIH is targeting to IPv6-only approach. As you indicated
it's doable for BIH with 464xlat and the draft already identify the
possibilities according to WG feedback,  I don't understand why not
intentionally allow them to be complementary.

> Saying "you can use BIH

Isn't our goal to identify the BCP? TCP is a standard, not BCP.

BRs

Gang

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 6 Sep 2012 18:39:01 +0200

> Missing BIH is incomplete when communication with IPv6 is needed.

Strictly speaking that is not true. The stateless NAT64 (4->6)
characteristic of  the clat gives 4-to-6 communication by default. What it
doesn't give is 4-to-6-internet , which BIH can arguably provide, but it is
certainly an additional option, rather than the core of what the xlat
solution is primarily intended for.

-Woj.

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Sep 2012 19:23:09 +0200

> Missing BIH is incomplete when communication with IPv6 is needed.

Although, as I have said,  don't see the reference to BIH as absolutely necessary in the 4X4XLAT draft, I think that not only it makes no harm but also is useful to clarify how IPv4-only applications can communicate, with standard-track RFCs, in IPv6-only environments .
I therefore don't understand reasons to insist that the existing complementarity of 464XLAT and BIH in this respect should no longer be mentioned.

At a time when there are still discussions on functional aspects of 464XLAT, this particular discussion is IMHO a waste of time.
Preferred approach: keep the sentence, and proceed. 

FWIW.

RD

> 
> 
> Strictly speaking that is not true. The stateless NAT64 (4->6) characteristic of  the clat gives 4-to-6 communication by default. What it doesn't give is 4-to-6-internet , which BIH can arguably provide, but it is certainly an additional option, rather than the core of what the xlat solution is primarily intended for.
> 
> -Woj.
> 
>

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 11:33:56 +0900

dear Remi,

as we are talking about a BCP, if 464xlat doc states BIH is an
indispensible part of the standard, our customers will require us to
definitely provide such a function or such an option rather than any other
alternatives in the service suite. i doubt this is the common
floor the working group is on.

(response to Gang's comment also...)

yes, i did reviewed all the thread you linked to me. thanks again for the
links. my observation is the authors accepted that phrase in order to move
on. i fully understand that but we are obliged to share our understanding
too, maybe late (if so i apologize). if we see something but not say
out, we were irresponsible to the community.
please also pay attention to the statement of the movitation in the
Introduction of the 464xlat:

   The 464XLAT architecture only supports IPv4 in the
   client server model, where the server has a global IPv4 address.
you argued that an IPv4 address is needed for the IPv6-translatable server
address, it is true and here you are, and, as Wojciech mentioned, CLAT has
supported that by default. we have no business with the IPv6-only server
without holding a global IPv4 address, in the problem scope!

on the other hand, *464xlat is indended to support IPv4-only application* -
this of your understanding, MHO, is biased from the above 464xlat problem
statement (it is also quite confusing me because, AFAIK, "BIH is indended
to support IPv4-only applications" :P :P :P).

therefore, IMHO, citing BIH is contradictory to the 464xlat problem
statement, making the document itself inconsistent.

- maoke

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

> Although, as I have said,  don't see the reference to BIH as absolutely
> necessary in the 4X4XLAT draft, I think that not only it makes no harm but
> also is useful to clarify how IPv4-only applications can communicate, with
> standard-track RFCs, in IPv6-only environments .
> I therefore don't understand reasons to insist that the
> existing complementarity of 464XLAT and BIH in this respect should no
> longer be mentioned.
>
> At a time when there are still discussions on functional aspects of
> 464XLAT, this particular discussion is IMHO a waste of time.

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 12:25:37 +0900

> 464XLAT, this particular discussion is IMHO a waste of time.

if we are not on the same floor of the problem statement and scope,
discussion on fuctional aspects would be trivial and possibly confusing. -
maoke

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 13:59:21 +0800

Hello Maoke,

2012/9/7, Maoke <[email-masked]>:
> definitely provide such a function

Different understanding. As we discussed and claimed, BIH is a
*complementary part* to 464xlat. That is only can make 464xlat better
and no harm. With the table of "Traffic Treatment Scenarios" in
section 9.2, it makes the applicability even more clear. Customers
could have their choice depending on their specific situation. Don't
do the definitive decision on behalf of your customer.

> or such an option rather than any other

The other alternatives you raised in other mail are identified as not
true. I'm still waiting your reply, which is better to be
point-by-point.

> on.

It is not our job to judge author decision. I believe their
prestigious knowledges. What I know is that is wg feedback.

>i fully understand that but we are obliged to share our understanding

I fully agree the more arguments create the good document.
However, groundless arguments can't help anything but waste our time.
The discussion on BIH was already taken several months.
If you haven't concrete argument and only insist on the claim,
we will be here for another month while that would delay the work.
Please to identify what the harm you see to object.  .

> address, it is true and here you are,

The sentence doesn't say the global IPv4 address SHOULD be a part of
IPv6-translatable server address.
That is a IPv4 server staying on the IPv4 area. It’s not what we are
talking about.

> and, as Wojciech mentioned, CLAT has

Didn't you notice the woj comments of *what it doesn't give is
4-to-6-internet , which BIH can arguably provide*
BTW, the statement of *The stateless NAT64 (4->6) characteristic of
the clat gives 4-to-6 communication* is strictly not true.
There is a condition that it's desirable to insert a global IPv4
addree. Otherwise, the feasibility should be discussed case by case.
Only state the sentence without the condition is a biased argument.
And I guess 464xlat situation can't be fall into the applicable scope.

> statement

No. it's identified in the draft in several places. Please search the
key of *applications*. You would get a good answer I guess.

(it is also quite confusing me because, AFAIK, "BIH is indended
> to support IPv4-only applications" :P :P :P).

Don't know what your confusion is. That is the same goal lets
464xlat&BIH could cooperate with each others.

> statement, making the document itself inconsistent.

I don't think that is a convinced conclusion. Please provide valid
technical justifications.

BRs

Gang

>>> > we do not yet have as much operational experience with it. So it
>>> > should
>>> not

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Sep 2012 15:13:53 +0900

> Missing BIH is incomplete when communication with IPv6 is needed.

CLAT also cannot communicate with DECNET. Should the 464xlat BCP mention
that CLAT can communicate with DECNET networks through a DECNET proxy? I
don't think so.

And before you say "CLAT is for providing IPv4 over IPv6, and so is BIH, so
BIH is in scope" - no, CLAT does not provide IPv4 over IPv6, it supports
IPv4 over IPv6 for a narrow subset of applications. Yes, it doesn't support
IPv6-only servers... but it also doesn't support raw IP packets, incoming
IPv4 connections, or IP options. Compared to those limitations, "doesn't
support IPv6-only servers" is franl

> surely should work with BIH.

The goal of 464xlat is to support IPv4-only clients. I would say that
supporting IPv6-only servers is out of scope of this BCP. Yes, you can do
it with BIH if you want. But you can also do it with transparent proxies,
ALGs, and so on. This document is not qualified to make the call on which
of these mechanisms to use.

> Isn't our goal to identify the BCP? TCP is a standard, not BCP.

This is a BCP for running IPv4-only client applications on an IPv6-only
network without encapsulation. This is not a BCP on how IPv4-only clients
should communicate with IPv6-only servers. Adding four lines lines to this
document that say "you can use BIH if you want" does not make it one.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Sep 2012 15:27:47 +0900

> Please to identify what the harm you see to object.  .

Ok, here's a concrete problem, then: the draft contradicts itself.

Section 1 says:

   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 [...]

But Section 2 says:

   This BCP only applies when the following two criteria are present:
[...]
   2.  There are IPv4-only applications or hosts that must communicate
       across the IPv6-only network to reach the IPv4 Internet.

So, one section mentions IPv6-only servers, and another section explicitly
says "the IPv4 Internet" where by definition, there cannot be IPv6-only
servers. So one section talks about IPv6-only servers, and another section
of the same document declares them to be out of scope.

In order to resolve the contradiction, either you modify Section 2 to
expand the scope to include IPv6-only servers, or you modify Section 1 to
remove the mention to BIH. Given the two choices I think it's better to
remove BIH, because as soon as IPv6-only servers are in scope, this
document will suddenly become a BCP on "how IPv4-only nodes should
communicate with IPv6-only servers", and I don't think we have consensus
that yet.

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 15:29:53 +0900

this item is what you are waiting for my reply to, right? see inline.

> If you have further point, please identify.

putting a microwave oven on the top of a fridge has no harm at all, too. my
point is simple: if 464xlat can solve the problem it identifies, then
things are enough. we don't need anything more, even the "anything" has
been standard, unless we change the scope of the problem.

> IPv6-only server is confused that outgoing packages should send to

not very understand. conflicted IPv4 address either causes trouble or
running as anycast. what's the scope?

> not really buy you anything.

i (the server) may keep early customers from native IPv4 having access
without knowing that i have changed my protocol stack and meanwhile
increase my native IPv6-only customers.

> 3) There no RFC stated the solution what you called as RFC6052+RFC6145;

copied from RFC6145:

   Readers of this document are expected to have read and understood the
   framework described in [RFC6144 <http://tools.ietf.org/html/rfc6144>].
Implementations of this IPv4/IPv6
   translation specification MUST also support the address translation
   algorithms in [RFC6052 <http://tools.ietf.org/html/rfc6052>].
Implementations MAY also support stateful
   translation [RFC6146 <http://tools.ietf.org/html/rfc6146>].
RFC6052 + RFC6145 is a MUST and both are standards.

and RFC6219 gave you an example of using the both in the practice.

> With 464xlat, we could easily do *combining 464XLAT with BIH*.

i think i don't misunderstand anything about your report. i read through
the mail and also the doc of the testing. it is good but i think it said,
BIH is working, no matter there is 464xlat or not. please identify the
benefit of having BIH working together with 464xlat, i.e., what we gain
through the combination rather than BIH and 464xlat themselves?

more comprehensively, if 464xlat provides A, BIH provides B, and 464xlat +
BIH provides A + B but nothing else, then i insist that it is not necessary
to cite BIH in 464xlat at all.

- maoke

> >> >    if combined with BIH [RFC6535 <http://tools.ietf.org/html/rfc6535
> >],
> >> is

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 15:54:49 +0900

2012/9/7 Lorenzo Colitti <[email-masked]>

+1

contradiction in text should be removed. we have had the consensus on the
scope of the problem and the 464xlat itself is a best current practice
regarding this specific problem. the complementary BIH is not necessary for
this scope.

- maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 09:21:27 +0200

Le 2012-09-07 à 04:33, Maoke a écrit :
...
> as we are talking about a BCP, if 464xlat doc states BIH is an indispensible part of the standard, our customers will require us to definitely provide such a function or such an option rather than any other alternatives in the service suite. i doubt this is the common floor the working group is on.
...

1. Stating that a combining 464XLAT with BIH is "possible" isn't stating it is "indispensable".
2. Being part of a a "BCP" isn't being part of a "standard".
3. Authors initially wrote "It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts." The added BIH reference better covers the original intent, by just stating a fact useful to be known. 

Confirmed stand:
- At a time when there are still discussions on functional aspects of 464XLAT, this particular discussion is IMHO a waste of time
- Preferred approach: keep the sentence, and proceed.

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Sep 2012 08:26:39 +0100

I have to say that I find any discussion of IPv6-only servers to be
very premature. Who would seriously advise a content provider or
application service provider to invest in IPv6-only services in
the next few years? Let's keep the topic to how to support *legacy*
clients reaching *legacy* services, which is a very real issue.

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Sep 2012 16:36:28 +0900

On Fri, Sep 7, 2012 at 4:21 PM, Rémi Després <[email-masked]>wrote:

> Confirmed stand:
> - At a time when there are still discussions on functional aspects of
> 464XLAT, this particular discussion is IMHO a waste of time

What does "confirmed stand" mean?

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 16:41:56 +0900

> alternatives in the service suite. i doubt this is the common floor the
> working group is on.
> ...
>

> 3. Authors initially wrote "It is also possible to provide single
> IPv4/IPv6 translation service, which will be needed in the future case of
> IPv6-only servers and peers to be reached from legacy IPv4-only hosts." The
> added BIH reference better covers the original intent, by just stating a
> fact useful to be known.
>

it is interesting. i don't think the authors were originally intent to
involve a helper for providing "single IPv4/IPv6 translation service". and
surely the phrase is correct, because CLAT supports IPv4/IPv6 single
translation without need anything more once the addressing support
statelessness; it is also happens between an IPv4 host in the Internet
having access to the native IPv6 server through the PLAT.

adding the BIH, is actually adding another solution to the CLAT box for
another problem, heavily biased from the original intent which contains
CLAT stateless single translation service and the PLAT stateful translation
service.

> 464XLAT, this particular discussion is IMHO a waste of time

scope and problem is more important than solution. waste of time is not an
execuse of passing misleading and confused sentences.

> - Preferred approach: keep the sentence, and proceed
>
>

i don't see this is the consensus of the WG. sorry.

- maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 09:50:23 +0200

Le 2012-09-07 à 09:36, Lorenzo Colitti a écrit :

> On Fri, Sep 7, 2012 at 4:21 PM, Rémi Després <[email-masked]> wrote:
> Confirmed stand:

Found in a dictionary: "stand" =  "an attitude toward a particular issue; a position taken in an argument".
I was just confirming, in general about this argument, a position previously expressed in a specific answer to Wojciech.
(Sorry if my English isn't for you as good as it should be ;-).)
 
RD

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 15:55:36 +0800

Hello Lorenzo,

> Ok, here's a concrete problem, then: the draft contradicts itself.

Thanks for providing the concrete point, I guess your intention is not
to identify the technical problem after the reading

> So, one section mentions IPv6-only servers,

Please note the condition is *combining 464XLAT with BIH*. The draft
clearly identifies that.
I don't see the harm if a draft to mention the possible relationship
with other from that same SDO considering same goal they would like to
achieve.

> and another section explicitly
> servers.

(*)The section 2 helps to justify the BCP applicability to
464xlat(i.e. IPv4 app through IPv6 network talk to IPv6 server). BIH
doesn't need to be justified in this draft, because it already a
standard track. It doesn't make sense to mix that with section 1
statement.
To be clear, the logic is
1) 464xlat is a BCP in the scenario of IPv4 app through IPv6 network
talking to IPv6 server. Section 2 help to answer that
2) BIH is a standard track solution in the scenario of IPv4 apps
talking to IPv6. The applicabilities are already justified in RFC6535.
 But mentioned the possibilities of cooperation are
informative/beneficial to readers.

>So one section talks about IPv6-only servers, and another section

If 464 BCP means the draft is only granted to talk about 464, which
exclude everything beyong the scope.
I would like to ask why "DNS Proxy Implementation" is ranked with
*SHOULD*. It should be out of the scope according to your logic.
But it's not true I guess, beacause it provides a valuable effcient
data path to 464xlat.
It's verified no technical harm and makes 464xlat is better.
The same reason is also applied to BIH.  Compared to that, BIH is only
*mentioned*

> communicate with IPv6-only servers", and I don't think we have consensus
I don't see the necessity. Please see(*)

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 09:59:20 +0200

> clients reaching *legacy* services, which is a very real issue.

As you may have noted, I fully agree that v4-only to v6-only isn't the most pressing issue.
Yet it is a fact the BIH RFC 6535 deals with it, and is on standard track. 
Just noting that BIH is complementary in a draft that deals with a related issue isn't, IMHO, a problem that justifies this last minute attack of a true statement.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 17:01:10 +0900

2012/9/7 GangChen <[email-masked]>

> talking to IPv6 server.

sorry, where in the Section 2 said 464xlat is a BCP in the scenario of IPv4
app through IPv6 network talking to *IPv6 server* ?? - maoke

> Section 2 help to answer that

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 10:03:51 +0200

Le 2012-09-07 à 09:41, Maoke a écrit :

> it is interesting. i don't think the authors were originally intent to involve a helper for providing "single IPv4/IPv6 translation service". and surely the phrase is correct, because CLAT supports IPv4/IPv6 single translation without need anything more once the addressing support statelessness; it is also happens between an IPv4 host in the Internet having access to the native IPv6 server through the PLAT.
>  
> adding the BIH, is actually adding another solution to the CLAT box for another problem, heavily biased from the original intent which contains CLAT stateless single translation service and the PLAT stateful translation service.
>  
> Confirmed stand:
> scope and problem is more important than solution. waste of time is not an execuse of passing misleading and confused sentences.

The sentence is AFAIK neither misleading nor confused.
Yes, 464XLAT and BIH have complementary targets and can usefully be combined.
> i don't see this is the consensus of the WG. sorry.

No claim there is a consensus.
Just stating a preference (my right I suppose). 

RD

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 17:09:23 +0900

dear Remi,

> Just noting that BIH is complementary in a draft that deals with a related
> issue isn't, IMHO, a problem that justifies this last minute attack of a
> true statement.
>

we can have a lot of complementaries. BIH does work with itself. in
practice it is fine if one would like to do that, but i doubt it should be
the "best" practice. on the other hand, i share Brian's point that right
now it is NOT the time to debate whether the BIH + 464xlat is a best
practice regarding the issue of accessing IPv6-only servers.

therefore i suggest we simply remove the statement and return to the common
floor of the problem that 464xlat focuses.

- maoke

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Sep 2012 17:14:59 +0900

On Fri, Sep 7, 2012 at 4:50 PM, Rémi Després <[email-masked]>wrote:

> I was just confirming, in general about this argument, a position
> previously expressed in a specific answer to Wojciech.

Ah. So it's *your* confirmed stand, and not anyone else's, right? In other
words, you are expressing your opinion to the list?

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 17:18:16 +0900

>> added BIH reference better covers the original intent, by just stating a
(#)  following point is emphasized

> CLAT stateless single translation service and the PLAT stateful translation
(/#) end of emphasis

> Yes, 464XLAT and BIH have complementary targets and can usefully be

AFAIK the sentence is misleading. 464 target is clearly described in
Section 2. the original intent of mentioning the IPv4/IPv6 single
translation was not a target, IMHO, but a natural result. it is fine not to
include the original intent if we think that is out of scope. it is also
fine to include that if we think that non-normative.

but replacing the original intent with statement on BIH actually made
things different. see my (#) that is emphasized above.

i may change the question: what BIH can gain from being combined with
464xlat? anything?

- maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 10:21:30 +0200

Le 2012-09-07 à 10:14, Lorenzo Colitti a écrit :

> On Fri, Sep 7, 2012 at 4:50 PM, Rémi Després <[email-masked]> wrote:
> 
> Ah. So it's *your* confirmed stand, and not anyone else's, right? In other words, you are expressing your opinion to the list?

Indeed, as usual.
(And surprised to be suspected to do otherwise!)
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 10:41:17 +0200

>> adding the BIH, is actually adding another solution to the CLAT box for another problem, heavily biased from the original intent which contains CLAT stateless single translation service and the PL…

The current sentence has been coined by authors themselves. 
It is therefore, presumably, compatible with their original intent.

I would really prefer to hear from you about 464XLAT with /64 delegated prefixes (and no NAT44 to be completely stateless), assuming you are also interested in _technical choices_ to be made before publication.

RD

> AFAIK the sentence is misleading. 464 target is clearly described in Section 2. the original intent of mentioning the IPv4/IPv6 single translation was not a target, IMHO, but a natural result. it is fine not to include the original intent if we think that is out of scope. it is also fine to include that if we think that non-normative.
>  
> but replacing the original intent with statement on BIH actually made things different. see my (#) that is emphasized above.
>  
> i may change the question: what BIH can gain from being combined with 464xlat? anything?
>  
> - maoke
>  
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Sep 2012 17:44:51 +0900

> issue isn't, IMHO, a problem that justifies this last minute attack of a

It's not a last-minute attack, we have had this conversation before. One
would imagine that last call is when unresolved disagreements need to be
resolved.

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 17:49:59 +0900

> It is therefore, presumably, compatible with their original intent.

i also didn't notice that there was actually the difference. so i will
appreciate if the authors may clarify.

>
> I would really prefer to hear from you about 464XLAT with /64 delegated
> prefixes (and no NAT44 to be completely stateless), assuming you are also
> interested in _technical choices_ to be made before publication.
>
>

i do not yet catch up in understanding the problem comprehensively of that
thread and i must firstly identify if my use-case fits that scenario. i
will do that as soon as possible.

- maoke

>> scope and problem is more important than solution. waste of time is not
>> an execuse of passing misleading and confused sentences.
>>
>>

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 17:53:08 +0900

2012/9/7 Maoke <[email-masked]>

> appreciate if the authors may clarify.

i mean i was not aware of that until recently. - maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 10:55:39 +0200

Le 2012-09-07 à 10:44, Lorenzo Colitti a écrit :

> On Fri, Sep 7, 2012 at 4:59 PM, Rémi Després <[email-masked]> wrote:
> It's not a last-minute attack, we have had this conversation before. One would imagine that last call is when unresolved disagreements need to be resolved.

This subject has AFAIK been stabilized for quite some time. 
Newcomers make a big deal, now where hopefully WG conclusion is close, of going backward by hiding a fact worth being known.
Waste of time IMHO.

RD

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 17:02:28 +0800

2012/9/7, Maoke <[email-masked]>:
> putting a microwave oven on the top of a fridge has no harm at all, too.

It's good to hear your confirmation on *NO harm*

> my
> been standard

No problem with 464xlat doing the best in 464. But the point is such
464 can't be guaranteed to be pure at different places and different
times in the real life. *Mentioned* that can only be informative and
benefit to reader. If we know the answer is good, why not do it?

> unless we change the scope of the problem.

No need. Please see my mail replying to Lorenzo.

> running as anycast. what's the scope?

The IPv4 embedded IPv6 address adopted by 464xlat is inserted with
private IPv4 address.
Those private IPv4 addresses are likely be same if two CLAT send
packages to a IPv6 server.
It's no problem with 464 communications because packages could be
identified by different IPv6 prefixes.
but it would be failed sending to a same IPv6 server, because replying
packages can't distinguish which packages should send to which prefix.
I hope you could understand.

> increase my native IPv6-only customers.

What I indicate is the needs to allocate the global IPv4 address to
server. It's nothing to do native IPv4 customer. But you seems mean
there is also need to customers assigning a global IPv4 address. It
seems getting that worse.

> RFC6052 + RFC6145 is a MUST and both are standards.

Please note RFC6145 is an algorithm block.
There is no justification of scenario applicability

> and RFC6219 gave you an example of using the both in the practice.

RFC6219 is informational. According to RFC2026, "An "Informational"
specification
is published for the general information of the Internet community,
and does not represent an Internet community consensus or recommendation. "

But BIH is a standard.

I guess what you have indentified is addressed totally.
I guess we could agree BIH is best selction if IPv4-IPv6 mentioned?

>> (**)I guess you will see the report soon, because we are coding that
>> right
>> now.
>> > not yet practiced. why we need/should put a stuff not yet practiced
>> > into
>> a
>> > BCP??
>>
> BIH is working, no matter there is 464xlat or not.

No. What I reported is our experience of BIH because 464xlat is not
appeared in that time.
I have to do in the way if 464 is unavoidable, even it was recommended
BIH should not work with NAT64 in RFC6535.
With 464xlat it's really perfect for us to follow and it's approved
that is a doable way and two technologies could benefit to each other.
We share the experiences and confirmed by wg.
Currently, you are coming here and say "Hi, I'm not happy with that
for no technical reasons, please remove it"
It's really unfair.

>please identify the

1) it gives the possibilities of 4-6 with a safe reference of standard track
2)it facilitates IPv6-only deployment
3)it's complementary to support IPv4 application
and etc.
As I said it would be better if you could progress the work with the
points that's didn't cover before
Otherwise, we would repeat the show several months ago

> BIH provides A + B but nothing else,

Please note A and B is closely realted. It has same goal/ mostly same
code/ same strategie.
A+B is doing a complete and concrete the use case to operators.

> then i insist that it is not necessary

That is surly known, even whatever happned in the wg and whatever we
are discussing.
Fortunately, it's approved that the adding BIH is no technial harm
after our discussion.

What needing clarification is already said on the list unless you
create an new point.

I intended to agree Remi comments
- At a time when there are still discussions on functional aspects of
464XLAT, this particular discussion is IMHO a waste of time
- Preferred approach: keep the sentence, and proceed.

BRs

Gang
>> >> > there could be several alternative ways to achieve that, why we
>> >> > should
>> >> > be
>> >> > bounded with BIH?
>> >> >

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Sep 2012 18:30:11 +0900

> for no technical reasons, please remove it"

But mentioning BIH in this document, when there are other ways for
IPv4-only clients to talk to IPv6-only servers (e.g., transparent proxies)
is unfair as well. If we want this document to include technologies to get
IPv4-only clients to communicate with IPv6-only servers, then we should
include those other ways as well.

> A+B is doing a complete and concrete the use case to operators.

I disagree that they are closely related. They are different problems, that
need to be solved on different timescales, using completely different
technologies. Problem A (IPv4-only application on IPv6-only network) is a
problem that operators are facing now. Problem B (IPv4-only client to
IPv6-only server) is not currently a problem at all. We should not mix the
two.

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 18:31:55 +0900

> It's good to hear your confirmation on *NO harm*

but we never see a fridge specification states or suggests: if you put your
oven on the top of the fridge, you can have icecream and meanwhile roast
your chicken. :P terrible specification if i have.

> benefit to reader. If we know the answer is good, why not do it?

as Lorenzo mentioned, we haven't confirm the answer is good or the best.
as Brian pointed out, it is too premature to talk about this.

why should we do it?

> I hope you could understand.

no. i don't know why the IPv6 server cannot distiguish the sources having
different IPv6 prefixes.

> seems getting that worse.

you misunderstood. i mean

   v4private client -> CLAT -> v6 server with IPv4-translatable
(global) address
   v6 client (native) -> <native IPv6-only network> -> v6 server with
IPv4-translatable (global) address

is the result. never talk about global ipv4 address for customers.

> >    framework described in [RFC6144 <http://tools.ietf.org/html/rfc6144
> >].

please argue this to the RFC6145 track.

> I guess we could agree BIH is best selction if IPv4-IPv6 mentioned?

no. your guess is wrong. personally i don't agree. i would like to say it
depends. it is a standard, but only a standard among an amount of. on other
hand, i don't like to debate this problem with you right now.

however, nobody stop you proposing a "BCP-target" draft for BIH usage,
standing on the BIH itself rather than borrowing another, with different
scope, as the ground of propaganda.

> >> > server, at least i have not seen any discussion/report from the
> authors
> >> or

i was talking about technical reasons but you never saw it. ;-) i cannot
help if you think the point on technical problem statement is not
technical.

- maoke

> >> > integrating the compressor, condenser, expansion valve, evaporator
> into
> >> > a

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 11:42:11 +0200

2012-09-07 11:30, Lorenzo Colitti :

> But mentioning BIH in this document, when there are other ways for IPv4-only clients to talk to IPv6-only servers (e.g., transparent proxies) is unfair as well. If we want this document to include technologies to get IPv4-only clients to communicate with IPv6-only servers, then we should include those other ways as well.

BIH is the only IETF specification for an IPv4-only application in a node attached to an IPv6-only network to reach an IPv6-only server WITHOUT depending on any special node between the two (transparent proxy or whatever). 
As such, it gracefully complements 464XLAT to facilitate IPv6-only deployments based on standard-track RFCs.

Justifications to hide it remain obscure.

RD 

> I disagree that they are closely related. They are different problems, that need to be solved on different timescales, using completely different technologies. Problem A (IPv4-only application on IPv6-only network) is a problem that operators are facing now. Problem B (IPv4-only client to IPv6-only server) is not currently a problem at all. We should not mix the two.

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 18:43:15 +0900

>> Just noting that BIH is complementary in a draft that deals with a
>> related issue isn't, IMHO, a problem that justifies this last minute attack
>> of a true statement.
>>
>
> Newcomers make a big deal, now where hopefully WG conclusion is close, of
> going backward by hiding a fact worth being known.
>
>

having BIH in this document will hide the fact, which is
worth knowing, that the WG doesn't have consensus on what is the really
best practice regarding the problem of IPv4-only to IPv6-only server, which
is not the main motivation of the original 464xlat.

> Waste of time IMHO.

newcomers waste your time. sorry for that.

- maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 11:52:23 +0200

Le 2012-09-07 à 11:31, Maoke a écrit :

> but we never see a fridge specification states or suggests: if you put your oven on the top of the fridge, you can have icecream and meanwhile roast your chicken. :P terrible specification if i have.
>  
> 
> 
> > my

Despite Lorenzo's comment, BIH is a standard-track RFC, and the only IETF-specified solution that addresses v4-only applications to v6-only servers, via v6-only networks, with the solution completely within the v4-only-application node.

> as Brian pointed out, it is too premature to talk about this.

Premature to give it a high priority, agreed, but not a reason for a pointer to a relevant standard-track RFC to raise such insisting objections.

RD

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 18:55:36 +0900

> BIH is the only IETF specification for an IPv4-only application in a node
> attached to an IPv6-only network to reach an IPv6-only server WITHOUT
> depending on any special node between the two (transparent proxy or
> whatever).
>
>

well, we see the scope changed by you again, different from Gang's
statement "BIH is the best if IPv4-v6 is mentioned". AFAIK, the wg haven't
discussed this scope in any thread up to now. on the other hand, it ignores
special node CLAT has been there. on the other hand, it ignores what PLAT
can provide.

>
> As such, it gracefully complements 464XLAT to facilitate IPv6-only
> deployments based on standard-track RFCs.
>
>

well, i prefer not to hide it too, by saying "BIH is a way for IPv4-only
client having access to IPv6-only servers but it is different from the
scope of this BCP, and therefore not yet identified as a best practice",
explicitly.

- maoke

> I disagree that they are closely related. They are different problems,
> that need to be solved on different timescales, using completely different

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Sep 2012 19:03:41 +0900

> depending on any special node between the two (transparent proxy or

And yet, before the problem it solves actually becomes a problem, things
could change substantially. New, better methods can come along. It could be
obsoleted. It could change. And we'd be stuck with a BCP that endorses
something that's not relevant any more. So if you really want to mention
IPv6-only servers, I would suggest replacing the current text with the
following:

464XLAT does not provide a means for IPv4-only applications to communicate
with IPv6-only servers. If this capability is necessary, 464XLAT can be
coupled with another transition mechanisms such as BIH [RFC6535].

That way it's clear that this document does not specify a best practice for
IPv4-only clients to talk to IPv6-only servers, but only for IPv4-only apps
on an IPv6-only network.

In any case, I think the following points have to be resolved before we can
make progress:

1. The conflict between section 1, which talks about IPv6-only servers, and
section 2, which declares them out of scope, must be resolved.
2. Before we mention BIH in this document, we should ensure that at least
one implementation of 464XLAT+BIH has been tested. We don't want to publish
a BCP that suggests doing something that has never been tested.
3. If this document suggests using 464XLAT + BIH together, it needs to say
why the text in the BIH RFC which says "Use of BIH together with a NAT64 is
NOT RECOMMENDED" is not relevant to this case.

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 12:08:38 +0200

Le 2012-09-07 à 11:43, Maoke a écrit :

> having BIH in this document will hide the fact, which is worth knowing, that the WG doesn't have consensus on what is the really best practice regarding the problem of IPv4-only to IPv6-only server,

This is new! 
Are you suggesting that v6ops objects to RFC 6535 being the standard-track RFC for its scope?

> which is not the main motivation of the original 464xlat.

> newcomers waste your time. sorry for that.

Newcomers are most welcome, and in most cases don't waste WG time!

But here, while the chair has insisted to close the discussion asap, insistently presenting last-minute objections to a sentence that is technically irreproachable, that just provides a useful information in its context, and has been stabilized for quite some time, is IMHO a waste of time for the WG.

RD

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 18:08:44 +0800

Hello Lorenzo,

> include those other ways as well.

1) CLAT in 464xlat is doing network level translation (RFC6145), it's
good compatible with BIH implementation (also RFC6145 is doing);
But transparent proxies is doing different thing from an application level.
I don't have experiences to say whether that is a feasible way doing
that on a energy- constrained terminal (e.g. a phone). But it can't be
confirmed the efficiency of network layer translation is advisable.

2) With my humble knowledge, I didn't find any standard track document
to state the *transparent proxies*. Especially, the processes of
IPv4->IPv6 translation.
I have found one, i.e. RFC1919, which is informational and released in
1999. If you have another, I'd happy to read and evaluate it.

> I disagree that they are closely related.

I agree the word *closely* may not accurate.
But can we agree it's related and has a possibility to cooperate to
make the thing better in an IPv6 deployment network?

>They are different problems, that

*IPv4-only application on IPv6-only network * is indeed the goal of RFC6535
http://tools.ietf.org/html/rfc6535

> IPv6-only server) is not currently a problem at all.

Yet. But the fact is (IPv4-only application on IPv6-only network) is a
superset of (IPv4-only client to IPv6-only server). And It is a fact
the BIH RFC 6535 deals with (IPv4-only client to IPv6-only server),
and is on standard track

> We should not mix the two.
>
We don't. As I clarified in
http://www.ietf.org/mail-archive/web/v6ops/current/msg14132.html,
it's clear. Hope we could accept.

Many thanks

Gang

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 19:13:15 +0900

> best practice regarding the problem of IPv4-only to IPv6-only server,
>
>
> This is new!

which scope? dear Remi, please you don't change the scope of RFC6535 too!
it is not the best practice for any IPv4-only client having access to
IPv6-only servers, IMHO, it might be best in some cases. i said, it
depends. - maoke

> But here, while the chair has insisted to close the discussion asap,
> insistently presenting last-minute objections to a sentence that is
> technically irreproachable, that just provides a useful information in its
> context, and has been stabilized for quite some time, is IMHO a waste of
> time for the WG.
>
> RD
>
>
>
>
>
>
> - maoke
>
>
>> RD
>>
>>

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 18:15:22 +0800

> app through IPv6 network talking to *IPv6 server* ?? - maoke

Please seriously read the rest of parts. No answer/reply would be treated as
acknowleged.

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 12:16:25 +0200

2012-09-07 12:03, Lorenzo Colitti :

> On Fri, Sep 7, 2012 at 6:42 PM, Rémi Després <[email-masked]> wrote:
> And yet, before the problem it solves actually becomes a problem, things could change substantially. New, better methods can come along. It could be obsoleted. It could change. And we'd be stuck with a BCP that endorses something that's not relevant any more. So if you really want to mention IPv6-only servers, I would suggest replacing the current text with the following:
> 
> 464XLAT does not provide a means for IPv4-only applications to communicate with IPv6-only servers. If this capability is necessary, 464XLAT can be coupled with another transition mechanisms such as BIH [RFC6535].
> 
> That way it's clear that this document does not specify a best practice for IPv4-only clients to talk to IPv6-only servers, but only for IPv4-only apps on an IPv6-only network.
> 
> In any case, I think the following points have to be resolved before we can make progress:
> 
> 1. The conflict between section 1, which talks about IPv6-only servers, and section 2, which declares them out of scope, must be resolved.
> 2. Before we mention BIH in this document, we should ensure that at least one implementation of 464XLAT+BIH has been tested. We don't want to publish a BCP that suggests doing something that has never been tested.

No new comment on the above.

> 3. If this document suggests using 464XLAT + BIH together, it needs to say why the text in the BIH RFC which says "Use of BIH together with a NAT64 is NOT RECOMMENDED" is not relevant to this case.

This is new consideration, but not a problem:
- The RFC says that BIH should not send packets to NAT64s.
- This doesn't prevent a node supporting BIH to also support 464XLAT which, precisely is designed to send packets to PLATs, AKA NAT64s.

This point underlines how complementary the two specifications are.

RD

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 19:23:38 +0900

> Please seriously read the rest of parts. No answer/reply would be treated

well. i answered here doesn't mean i didn't read the rest. the Section 2
doesn't talk about IPv6-only server and therefore MHO is your 1) and 2) are
not qualified. - maoke

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Sep 2012 19:36:05 +0900

On Fri, Sep 7, 2012 at 7:16 PM, Rémi Després <[email-masked]>wrote:

> - This doesn't prevent a node supporting BIH to also support 464XLAT
> which, precisely is designed to send packets to PLATs, AKA NAT64s.
>

If you don't want to remove BIH, then please suggest text to address this
issue. The text that is currently in the draft does not do so, and since
it's a conflict with a standards track RFC, we have to say something about
it.

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 18:45:33 +0800

Hello Maoke,

2012/9/7, Maoke <[email-masked]>:
>> >> > 1. i don't think an early conclusion of the authors cannot be
>> >> > objected
>> >> and
>> >> > 2. i don't think it is a loss to state out of scope (or not to
>> >> > mention
>> >> that
> your chicken. :P

Beacause we are discussing the BCP in telecom area, not house decoration :)

>terrible specification if i have.
>
>>
>>
>> > my

So that is the discussion to help the confirm

> as Brian pointed out, it is too premature to talk about this.

The point should better be discussed on the Behave
But the fact is BIH is standard track, we should follow the guidance of RFC2026

>> > running as anycast. what's the scope?

what I mean is *replying packages*, because the destination would be
same IPv4 address.

>    v4private client -> CLAT -> v6 server with IPv4-translatable
^^^^^^^^^^

that is what I talking about

> IPv4-translatable (global) address

that is a native IPv6 communication.
Why do you assign the IPv4-translatable (global)IPv6 address to server.
BTW, I guess that is not the case we are talking about

> please argue this to the RFC6145 track.

Don't understand
You mentioned that is qualified, so we need specific texts to approve
the scenario applicability.

> depends. it is a standard, but only a standard among an amount of.

Amount of what? Intentional avoiding could not help you to clarify.
It's only can delay the work

> on other

it's up to you. But the work still needs to progress.
> however, nobody stop you proposing a "BCP-target" draft for BIH usage,

No. The justification of BIH usage was already done in RFC6535. There
are no needs stated in this draft.

> scope, as the ground of propaganda.

I did serious works to reply you point-by-point.

BRs

Gang
>> > more comprehensively, if 464xlat provides A, BIH provides B, and
>> > 464xlat
>> +
>> >> > service" itself. BIH has done the single IPv4/IPv6 translation
>> >> > right?
>> >> what
>> >> >> > it sounds to me that 464xlat does suggest to apply BIH, as part
>> >> >> > of
>> >> >> > the
>> >> >> best

---

From: t.petch <[email-masked]>
Date: Fri, 7 Sep 2012 11:38:44 +0100

Cameron

Just to clarify, in your point 3), is the emphasis on 'standard', that
is that ND-Proxy is not on standards track?

I see sharing a /64 as just another example of NBMA, which IPv6 sort of
supports.  In this case, the 464 device is the hub and the IPv6 access
network one spoke and the downstream devices another set of spokes.  OK,
the downstream devices may think that they are broadcast but they are
not, they are NBMA in this case.

Tom Petch

----- Original Message -----
From: "Cameron Byrne" <[email-masked]>
To: "Rémi Després" <[email-masked]>
Cc: "v6ops WG" <[email-masked]>
Sent: Thursday, September 06, 2012 4:27 PM
Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes

Rémi ,

>>> how can we ensure the above addresses do not conflict with any
manually,
>> AIUI, we say "conflicts are impossible, because this is a reserved
range",

http://keithbartholomew.com/2012/04/how-att-u-verse-broke-my-home-networ
k/

> Still convinced to be one of the best supporters of a good 464XLAT
without
> undue delay,

Thanks again!

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 19:54:51 +0900

> That way it's clear that this document does not specify a best practice
> for IPv4-only clients to talk to IPv6-only servers, but only for IPv4-only
> apps on an IPv6-only network.
>
> 1. The conflict between section 1, which talks about IPv6-only servers,
> and section 2, which declares them out of scope, must be resolved.

actually, Remi, i have to point out it is problem. this is related to my
talk with you that the private addresses are also possibly used for a
server.

0. the domain operator makes address planning with the private address in
order to avoid potential conflict;
1. a host having private IPv4 address are located in a LAN behind BIH/CLAT
box, with IPv6 prefixes configured with the box;
2. it is running a server and a client peer behind another CLAT, somehow,
know the server's address (it is private but static);
3. the client sends out a request to the server's IPv4 address, both src
and dst are translated by the CLAT statelessly;
4. the CLAT of the server side decodes the IPv4-converted addresses and
delivered the translated packet to the server;
5. the server responds the request, while the reply arrives at the
BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT,
fortunately, we are lucky, and things just worked as IVI with double
translation. if BIH takes the session, well, what would happen? i don't
think BIH is covering this case too with its synthetic IPv4 and the real
IPv6 addresses because the peer (the client) is not IPv6 now at all. BIH
state needs to be established by the initiator of the session but combining
it with CLAT makes it uncertain when the initiation bypasses BIH at all.

this is a very realistic case when we want to deploy an in-domain server
group. and 464xlat itself can works well. but the combination of 464xlat to
BIH may cause some trouble. Lorenzo and me argued that the combination was
not tested. this is a real case of risk. of course, we may patch it, but it
is definitely far beyond one paragraph stating that "combining them is
useful".

if we have time, i may find more and more cases where the combination
introduces uncertainty. therefore i think it is safe to scope out the
problem right now.

- maoke

---

From: t.petch <[email-masked]>
Date: Fri, 7 Sep 2012 11:55:57 +0100

----- Original Message -----
From: "Lorenzo Colitti" <[email-masked]>
To: "Rémi Després" <[email-masked]>
Cc: "v6ops WG" <[email-masked]>
Sent: Thursday, September 06, 2012 8:48 AM
On Thu, Sep 6, 2012 at 4:20 PM, Rémi Després

<tp>
My answer would be yes, or, more colloquially, 'RTFM':-)

The cited section says

" IANA EUI-64 identifier allocations under the
   IANA OUI must meet the following requirements:

      o  must be for standards purposes (either for an IETF Standard or
         other standard related to IETF work),

      o  must be for a block of a power-of-two identifiers starting at a
         boundary which is an equal or greater power of two, including
         the allocation of one (2**0) identifier,

      o  must not be used to evade the requirement for vendors to obtain
         their own block of identifiers from the IEEE, and

      o  must be documented in an Internet Draft or RFC.

   In addition, approval must be obtained as follows (see the procedure
   in Section 5.1):

      Small to medium allocations of a block of 1, 2, 4, ..., 134217728,
         268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28) EUI-64
         identifiers require Expert Review.

      Allocations of any size, including 536870912 (2**29) or more
         EUI-64 identifiers, may be made with IESG Ratification (see
         Section 5.1).

   To simplify record keeping, all allocations of 65536 (2**16) or less
   EUI-64 identifiers shall have the Group bit unspecified, that is,
   shall be allocations of parallel equal size blocks of multicast and
   unicast identifiers, even if one of these two types is not needed for
   the proposed use"

so no problem with IANA.

As at the time of this message, the indicated addresses are available.
IANA calls them Ethernet numbers rather than OUI.

Tom Petch

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 20:09:22 +0900

> what I mean is *replying packages*, because the destination would be

they have different IPv6 prefixes and routing can guide them to different
CLATs. what the problem?

> >    v4private client -> CLAT -> v6 server with IPv4-translatable

see above, what's the problem?

> BTW, I guess that is not the case we are talking about

i just answer your previous question why someone may be interested to
deploy IPv6-only server with IPv4-translatable address. the reason is
enlarging the connectivity to native IPv6 clients without losing the
services to original IPv4 clients. yes, this is out of scope but try to
share my understanding with answer your question.

> the scenario applicability.

i mean RFC6145 is working with RFC6052 -- this is a normative statement in
the standard RFC6145.

> >> and does not represent an Internet community consensus or
> recommendation.
> >> "
> >>
> >> But BIH is a standard.
> >>

com'on. an amount of standards.

> I did serious works to reply you point-by-point.

thanks a lot. i just try to make the answer as brief as possible because
our discussion dispersed much.

- maoke

> >> >> > in anyway not necessarily the socket layer solution, even though
> BIH
> >> >> > does
> >> >> At this stage, what I can tell is most parts are same in the
> combining
> >> >> code.
> >> >>
> >> >> >> >> I should note that the current thread has a subject line
> reading
> >> >> >> -06.txt,
> >> >> >> >> >  "464XLAT: Combination of Stateful and Stateless
> Translation",
> >> >> >> Masataka

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 19:28:06 +0800

> it with CLAT makes it uncertain when the initiation bypasses BIH at all.

The packages are headed to CLAT is identified by the destination
address with TUN IPv6 address; the packages heading to BIH are with
IPv6 destination that matches the mapping table. That is
implementation detailed. I believe there are multiple ways could do
that. What the trouble you can see?

BRs

Gang

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 19:31:36 +0800

2012/9/7, Maoke <[email-masked]>:
> not qualified.

But the point is the applicabilities of BIH don't not need to be
stated in 464xlat. It's already covered in RFC6535.

>> >> > expand the scope to include IPv6-only servers, or you modify Section
>> >> > 1
>> >> > to

---

From: Ray Hunter <[email-masked]>
Date: Fri, 07 Sep 2012 14:15:15 +0200

Interesting perspective.

Would you recommend sharing a NBMA network across an AS boundary where 
there are also potential parallel paths?

What is then "downstream"? What is "upstream"? Which device is the "hub"?

That's my concern with tethering one or more mobile phones to a home 
network, where there are also likely to be existing "uplinks" to other 
ISPs / IPv6 access networks.

regards,
RayH

t.petch wrote:
> From: "Cameron Byrne"<[email-masked]>
> To: "Rémi Després"<[email-masked]>
> Cc: "v6ops WG"<[email-masked]>
> On Thu, Sep 6, 2012 at 7:22 AM, Rémi Després<[email-masked]>
> wrote:
>> On Sep 6, 2012 1:03 AM, "Lorenzo Colitti"<[email-masked]>  wrote:
>>> On Thu, Sep 6, 2012 at 4:54 PM, Maoke<[email-masked]>  wrote:
>> with well-behaved hosts =The need to cross fingers is permanent ;-).
>

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 15:06:34 +0200

Le 2012-09-07 à 12:36, Lorenzo Colitti a écrit :

> On Fri, Sep 7, 2012 at 7:16 PM, Rémi Després <[email-masked]> wrote:
> If you don't want to remove BIH, then please suggest text to address this issue. The text that is currently in the draft does not do so, and since it's a conflict with a standards track RFC, we have to say something about it.

As said, I don't think there is a problem in cohabitation of 464XLAT, by design used with NAT64, and BIH whose use with a NAT64 isn't recommended.

Yet, if this covers your concern, and raises no objection from authors, the last paragraph of section 1 could be completed, e.g. as follows:
"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 IPv4-only hosts across IPv6-only networks. By doing so, BIH continue to not be used together with a NAT64, as recommended in [RFC6535], 464XLAT being in charge of using NAT64s as PLATs."
Could this be a way out of this endless debate?

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 7 Sep 2012 06:41:04 -0700

Yes.

> not, they are NBMA in this case.

Interesting. Is there an existing standards track doc that describes this
behavior for ipv6 accross L3 interfaces?

Is there an implementation to reference?

This is a fair case, but i tend to think it is another very feasible
implementation option that is best for the implementers to balance. I do
not believe there is an easy case for this behavior to be described
generically in 464xlat.

CB

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 15:59:50 +0200

Maoke,

Your scenario below is out of scope (see reasons below), but it has the interesting advantage of pointing out that a correction is needed, in the current draft, in the paragraph about BIH:  BIH scope is IPv4-only APPLICATIONS that reach IPv6-only servers, not IPv4-only HOSTS as written. 

Dealing also with Lorenzo's point, this  paragraph could then become:
"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 to be reached across IPv6-only networks from IPv4-only applications in CLAT nodes. (By doing so, BIH continue to not be used together with a NAT64, as recommended in [RFC6535], 464XLAT being in charge of using NAT64s as PLATs.)"

Two points make your scenario off-cope:
- as reminded above, BIH is not for applications in IPv4-only hosts (only for applications in hosts that support BIH).
- CLATs only treat outgoing connections, thus excluding CLAT-to-CLAT scenarios.
Yet, thanks for this detailed case. It proved to be useful.

Regards,
RD

Le 2012-09-07 à 12:54, Maoke a écrit :

> actually, Remi, i have to point out it is problem. this is related to my talk with you that the private addresses are also possibly used for a server.
>  
> 0. the domain operator makes address planning with the private address in order to avoid potential conflict;
> 1. a host having private IPv4 address are located in a LAN behind BIH/CLAT box, with IPv6 prefixes configured with the box;   
> 2. it is running a server and a client peer behind another CLAT, somehow, know the server's address (it is private but static);
> 3. the client sends out a request to the server's IPv4 address, both src and dst are translated by the CLAT statelessly;
> 4. the CLAT of the server side decodes the IPv4-converted addresses and delivered the translated packet to the server;
> 5. the server responds the request, while the reply arrives at the BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT, fortunately, we are lucky, and things just worked as IVI with double translation. if BIH takes the session, well, what would happen? i don't think BIH is covering this case too with its synthetic IPv4 and the real IPv6 addresses because the peer (the client) is not IPv6 now at all. BIH state needs to be established by the initiator of the session but combining it with CLAT makes it uncertain when the initiation bypasses BIH at all.
>  
> this is a very realistic case when we want to deploy an in-domain server group. and 464xlat itself can works well. but the combination of 464xlat to BIH may cause some trouble. Lorenzo and me argued that the combination was not tested. this is a real case of risk. of course, we may patch it, but it is definitely far beyond one paragraph stating that "combining them is useful". 
>  
> if we have time, i may find more and more cases where the combination introduces uncertainty. therefore i think it is safe to scope out the problem right now.
>  
> - maoke
>  
>

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 23:21:37 +0900

在 2012年9月7日星期五，GangChen 写道：

> 2012/9/7, Maoke <[email-masked] <javascript:;>>:
> > 2012/9/7 Rémi Després <[email-masked] <javascript:;>>
> >
> >>
> >> On Fri, Sep 7, 2012 at 6:42 PM, Rémi Després
> >> <[email-masked] <javascript:;>>wrote:
> >>

1. no business with TUN in 464xlat, IMHO.
2. "you believe" is not an approval for a BCP.

enough.

- maoke

> >> [email-masked] <javascript:;>

---

From: t.petch <[email-masked]>
Date: Fri, 7 Sep 2012 15:25:38 +0100

----- Original Message -----
From: "Cameron Byrne" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "v6ops WG" <[email-masked]>
Sent: Friday, September 07, 2012 2:41 PM

Yes.

> not, they are NBMA in this case.

Interesting. Is there an existing standards track doc that describes
this
behavior for ipv6 accross L3 interfaces?

Sorry no, no standard or implementation as far as I know, rather it is
how I view it analytically (as perhaps does Fred when he said
"ND Proxy is designed for the Non-Broadcast Multi-access case.").

There may be a tendency to view the world radiating out from the ISP,
from the CLAT, whereas sometimes it makes more sense (to me) to view the
PLAT as the centre of the world.

Tom Petch
</tp>

CB

> > This "sarcasm" isn't deserved: one who manually configures a host
with
> an
> k/
>
>
> > Besides, it is particularly unexpected from you, after you stated
"In
> > By using the proposed IANA-EUI-64 based /96, this is avoided and,
with
> a MAY
> > concensus. If we do not limit the scope to the core objective we
will

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 23:37:44 +0900

在 2012年9月7日星期五，Rémi Després 写道：

> Maoke,
>
> Your scenario below is out of scope (see reasons below),
>

what i propased is always out of scope. what you proposed is always in.
well, i said the combination is harmful technically. even if the wg agrees
the scenario is out of scope, i require a paragraph stating that:

  the 464xlat itself, even out of scope of the design motivation, can also
naturally support mesh communication once the private addresses are planned
and statically assigned to in-domain servers. if it is combined with BIH,
however, such a naturally enabled feature would be in trouble.

with such a explicit explanation, i could accept what you seggest below.
otherwise i don't accept the confusion. sorry to the chair and the authors!

- maoke

> but it has the interesting advantage of pointing out that a correction is
> needed, in the current draft, in the paragraph about BIH:  BIH scope is
> IPv4-only APPLICATIONS that reach IPv6-only servers, not IPv4-only HOSTS as
> written.
>
> "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 to be reached across IPv6-only networks fromti
> IPv4-only applications in CLAT nodes. (By doing so, BIH continue to not be
> used together with a NAT64, as recommended in [RFC6535], 464XLAT being in
> charge of using NAT64s as PLATs.)"
>
> - as reminded above, BIH is not for applications in IPv4-only hosts (only
> for applications in hosts that support BIH).

---

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 22:44:18 +0800

2012/9/7, Maoke <[email-masked]>:
>> >> could change substantially. New, better methods can come along. It
>> >> could
>> >> be
>> >> In any case, I think the following points have to be resolved before
>> >> we
>> >> can make progress:
>> >>
>> >> why the text in the BIH RFC which says "Use of BIH together with a
>> >> NAT64
>> >> is

AFAICS, http://www.ietf.org/mail-archive/web/v6ops/current/msg12664.html

>> > group. and 464xlat itself can works well. but the combination of
>> > 464xlat
>> to
>> > not tested. this is a real case of risk. of course, we may patch it,
>> > but
>> it

---

From: t.petch <[email-masked]>
Date: Fri, 7 Sep 2012 15:54:11 +0100

----- Original Message -----
From: "Fred Baker (fred)" <[email-masked]>
To: "v6ops WG" <[email-masked]>
Sent: Wednesday, September 05, 2012 7:31 PM

<chair>
The purpose of a WGLC is, as you say, to ensure that important concerns
have not been missed or misunderstood. It is not to to prove or create
unanimity of viewpoint, although that would be a happy outcome. If in
the opinion of the chairs all opinions have been expressed and new
issues are not being raised, a single person or small group that
disagrees with the outcome is consistent with "rough consensus".

I note that this morning we have additional comments from Ray and Woj,
which I think need to be heard and addressed. So I'll let the WGLC
continue the remainder of this week to see what additionally shakes
loose. Note to the authors: we will need a -08 as an outcome of the
WGLC.

</chair>

<tp>

Based on what has emerged in the WGLC, there are two points I would like
to see strengthened in the I-D.

One is that while DHCPv6-PD can be expected in a 'wired' environment,
the same is not true in a 'weird' environment, at least for the
foreseeable future.  Perhaps in s.8.2.1, add
"While DHCPv6-PD is the most straightforward way to implement 464XLAT,
this function is not widely available in current 3GPP networks nor is it
likely to be for some time, perhaps years, to come."

Second, support for tethering is a necessity but cascading 464XLAT is
not.  I am not sure where this should go, perhaps s.6 after
"Wireless 3GPP Network Architecture can fit in the situations that
   client and node that terminate access network is same host in the
   same way"
(which itself is a sentence I would like reworded - I don't know what it
means:-(

Something like
"In a wireless environment, 464XLAT provides support for tethered
devices but this does not extend to the cascading of 464XLAT devices"

I want to see this I-D progress but switched my view from 'support' to
'more work needed' based on what emerged in WGLC.  These two points
are - shock horror - not based on my own external experience but on my
judgement of what has been expressed on this list during WGLC, that is
that they need incorporating somewhere.

Tom Petch

<snip>

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 7 Sep 2012 08:00:07 -0700

>>>>
>>>> adding the BIH, is actually adding another solution to the CLAT
box for another problem, heavily biased from the original intent which
contains CLAT stateless single translation service and the PLAT stateful
translation service.
> It is therefore, presumably, compatible with their original intent.

Confirmed.

In the best interest of making a complete bcp for the stated scope that is
timeless, as represented by the traffic treatment table, bih fills a hole
that makes that table symmetric and complete. Removing or adding bih does
not change the scope or motivation, the reference to bih is just a pointer
for future scenarios that was discussed on the list and vetted some time
back.

Pardon me for being synical. It is my fear that we are not actually having
a discussion about 464xlat but a proxy fight with a "competing" i-d.
Otherwise, i cannot understand so many last minute passionate debates over
truly fringe issues. .. And calls for defining 464xlat in terms of map-t
and not any other solution.

Once again, pardon me, i hope it is not the case.

CB

>>>>
>>>>
>>>> scope and problem is more important than solution. waste of time is
not an execuse of passing misleading and confused sentences.
464xlat? anything?

---

From: Maoke <[email-masked]>
Date: Sat, 8 Sep 2012 00:00:47 +0900

hi Lorenzo,

在 2012年9月7日星期五，Rémi Després 写道：

> On Fri, Sep 7, 2012 at 7:16 PM, Rémi Després <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> 3. If this document suggests using 464XLAT + BIH together, it needs to
>> say why the text in the BIH RFC which says "Use of BIH together with
>> a NAT64 is NOT RECOMMENDED" is not relevant to this case.
>>
>>
> As said, I don't think there is a problem in cohabitation of 464XLAT, by
> design used with NAT64, and BIH whose use with a NAT64 isn't recommended.
>
> Yet, if this covers your concern, and raises no objection from
> authors, the last paragraph of section 1 could be completed, e.g. as
> follows:
>
> thanks for the composing. it is constructive. however,

single ipv4 to ipv6 translation service is provides by any standard fitting
RFC6144 framework. 464xlat itself can provide this with special addressing.
BIH can provide this independently too. and i didn't see any effort and
benefit of the "combination" rather than only putting them together.

my suggestion:

"464xlat is not designed to cover the case of IPv4-only applications having
access to IPv6-only servers, which will be possibly needed in the future.
Together using it with BIH [RFC6535] can be a feasible solution, if this
demand becomes true, and we leave the details of the co-existance to the
implemantaion. By doing so, BIH continue to not be used together with a
NAT64, as recommended in [RFC6535], while 464xlat is being in charge of
using NAT64s as PLATs."

if this is acceptable, i end debating soon.

- maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 17:04:42 +0200

> what i propased is always out of scope. what you proposed is always in.

It would be nicer if you could refrain from such statements (undeserved IMHO).

> well, i said the combination is harmful technically. even if the wg agrees the scenario is out of scope, i require a paragraph stating that: 
> 
>   the 464xlat itself, even out of scope of the design motivation, can also naturally support mesh communication once the private addresses are planned and statically assigned to in-domain servers. if it is combined with BIH, however, such a naturally enabled feature would be in trouble. 

CLATs send ALL translated packets to PLATs, aka NAT64s, where they are translated to IPv4 enter the IPv4 Internet, a purely hub&spoke topology .
In this context your sentence would AFAIK not add any useful clarification, and would confuse readers.

> with such a explicit explanation, i could accept what you seggest below. otherwise i don't accept the confusion. sorry to the chair and the authors!

I hope that after thinking it over, you can release your condition to acceptance.

RD

> 
> - maoke
>  
> but it has the interesting advantage of pointing out that a correction is needed, in the current draft, in the paragraph about BIH:  BIH scope is IPv4-only APPLICATIONS that reach IPv6-only servers, not IPv4-only HOSTS as written. 
> 
> "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 to be reached across IPv6-only networks fromti IPv4-only applications in CLAT nodes. (By doing so, BIH continue to not be used together with a NAT64, as recommended in [RFC6535], 464XLAT being in charge of using NAT64s as PLATs.)"
>

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 17:17:36 +0200

Le 2012-09-07 à 17:00, Maoke a écrit :

> single ipv4 to ipv6 translation service is provides by any standard fitting RFC6144 framework. 464xlat itself can provide this with special addressing. BIH can provide this independently too. and i didn't see any effort and benefit of the "combination" rather than only putting them together. 
> 
> my suggestion: 
> 
> "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers, which will be possibly needed in the future. Together using it with BIH [RFC6535] can be a feasible solution, if this demand becomes true, and we leave the details of the co-existance to the implemantaion. By doing so, BIH continue to not be used together with a NAT64, as recommended in [RFC6535], while 464xlat is being in charge of using NAT64s as PLATs."
>  

I wouldn't oppose this wording as is, but think it can be improved by deleting "which will be possibly needed in the future" and "if this demand becomes true".
Reasons are that RFC6535 has no such caveat, and that some WG members think this need can usefully be satisfied now.

Regards,
RD

---

From: Hui Deng <[email-masked]>
Date: Fri, 7 Sep 2012 23:27:47 +0800

Those people haven’t been involved in contributing any text and never
showing up for the disucssion about xlat464, but working on some other
solution, that is not appropriate for them to jump in the last minute, we
need to respect IETF.

-Hui

2012/9/7 Cameron Byrne <[email-masked]>

> >>>> it is interesting. i don't think the authors were originally intent
> to involve a helper for providing "single IPv4/IPv6 translation service".
> and surely the phrase is correct, because CLAT supports IPv4/IPv6 single
> >>>>> - At a time when there are still discussions on functional aspects
> of 464XLAT, this particular discussion is IMHO a waste of time
> >>>>
> >>>>

---

From: Maoke <[email-masked]>
Date: Sat, 8 Sep 2012 00:30:11 +0900

dear Cameron,

well, fringe issues...last minutes... i can "mitfuelen" but a little
disappointed. as i am free, no MAP-T, no my company, no any other persons,
asking me to fight in the last minutes. the timing is just because i was
too busy.

the one who should say pardon is me. pardon me for not proposing this issue
in the earlier discussions. pardon me, especially to Remi, that i always
dislike the "out of scope" but you were possibly right.

but honestly speaking, i now have to choose MAP-T for my company as we have
the demand of the mesh communications for in-domain servers that originally
464xlat could support. just a little pity.

have a nice weekend to everyone!!

- maoke

P.S., i responded to Lorenzo's proposal on the modified text. now i show my
respect to the authors' understanding.
2012/9/8 Cameron Byrne <[email-masked]>

---

From: Maoke <[email-masked]>
Date: Sat, 8 Sep 2012 00:32:41 +0900

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

> single ipv4 to ipv6 translation service is provides by any standard
> fitting RFC6144 framework. 464xlat itself can provide this with special
> addressing. BIH can provide this independently too. and i didn't see any
> effort and benefit of the "combination" rather than only putting them
> together.
>
> my suggestion:
>
> "464xlat is not designed to cover the case of IPv4-only applications
> having access to IPv6-only servers, which will be possibly needed in the
> future. Together using it with BIH [RFC6535] can be a feasible solution, if
> this demand becomes true, and we leave the details of the co-existance to
> the implemantaion. By doing so, BIH continue to not be used together with a
> I wouldn't oppose this wording as is, but think it can be improved by
> deleting "which will be possibly needed in the future" and "if this demand
> becomes true".
> Reasons are that RFC6535 has no such caveat, and that some WG members
> think this need can usefully be satisfied now.
>
>

acceptable. i appreciate your kindness. - maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 17:34:30 +0200

Le 2012-09-07 à 17:32, Maoke a écrit :
...

> acceptable. i appreciate your kindness. - maoke 

I see this as a breakthrough.
Hope authors can agree.

Have a nice WE.
RD

---

From: Maoke <[email-masked]>
Date: Sat, 8 Sep 2012 00:41:27 +0900

Hui,
2012/9/8 Hui Deng <[email-masked]>

> solution, that is not appropriate for them to jump in the last minute, we

i really won't like to debate with you on this childish statement,
especially i am friend of you for more than 10 years. :) just execuse
me for participating late.

- maoke

---

From: Maoke <[email-masked]>
Date: Sat, 8 Sep 2012 00:43:21 +0900

> I see this as a breakthrough.

same to you. and please accept my sorry for the impolite wording before (i
know me but i sometimes less controlled) and sorry for the late
participation in the discussion. - maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 17:46:56 +0200

Le 2012-09-07 à 17:43, Maoke a écrit :

> same to you. and please accept my sorry for the impolite wording before (i know me but i sometimes less controlled) and sorry for the late participation in the discussion. - maoke

No problem between us. 
As usual, something useful can be achieved at the end.
RD

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 7 Sep 2012 08:47:31 -0700

On Fri, Sep 7, 2012 at 8:30 AM, Maoke <[email-masked]> wrote:
> asking me to fight in the last minutes. the timing is just because i was too
> busy.
>

I do appreciate feedback at any time, it makes us all stronger,
thanks again for taking the time to review and even more for
suggesting text.  Text is always the best since it makes the desired
outcomes clearest.

> 464xlat could support. just a little pity.

Yes, there must be many solutions.  If we had all moved to IPv6 10
years ago .... maybe this would be easier :)

>> truly fringe issues. .. And calls for defining 464xlat in terms of map-t and
>> not any other solution.
>>

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 17:56:07 +0200

Hi, Tom, 

Thanks for the clarification about IANA vocabulary (I hadn't checked www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet-numbers-4).

With the IANA-related FUD eliminated, and with the common wish to support /64 delegated prefixes, do you agree that, with the reserved ranges below, 464XLAT can be implemented:
- without interfering with the approach chosen for tethering and /64
- completely statelessly (no NAT44 needed).

If not, requests for clarification are welcome.  

Regards,
RD 

...

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 7 Sep 2012 18:14:26 +0200

> and not any other solution.
You'll likely find that the discussion is about the WG last call, which
often prompts people to actually read drafts.
Now,  this thread specifically appears to be about BIH which does not
appear to be a core component of xlat, but an add-on. No problem if someone
wants to use BIH, but it is as someone said before effectively as "putting
a toaster on a fridge" (or perhaps inside it).
In terms of the relationship to other work, perhaps it would be good to put
to rest the fact that there is the notion of a NAT464 architecture that is
not unique to xlat, and describe in the draft what the xlat solution
uniquely delivers in that. As per text suggested elsewhere, xlat appears to
have some unique points.

Cheers,
Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 7 Sep 2012 18:25:13 +0200

You may want to re-read:

"must be for standards purposes (either for an IETF Standard ..."

Such an assignment is a standards action item, and last I checked we were
not defining a new standard here.
Furthermore, the actual call for such a reservation appears not to be
needed, if we get over the fact that a routed mode + pd is better at
handling this case.

Cheers,
-Woj.

On 7 September 2012 17:56, Rémi Després <[email-masked]> wrote:

> Hi, Tom,
>
> Thanks for the clarification about IANA vocabulary (I hadn't checked
> www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet-numbers-4
> ).
>
> With the IANA-related FUD eliminated, and with the common wish to support
> /64 delegated prefixes, do you agree that, with the reserved ranges below,
> 464XLAT can be implemented:

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 19:18:31 +0200

2012-09-07 18:25, Wojciech Dec :

> Such an assignment is a standards action item, and last I checked we were not defining a new standard here.

!!!
Let's hope its isn't on purpose, to support an unjustified argument, that you truncated the quoted sentence of RFC5342. 
The full sentence is:
"must be for standards purposes (either for an IETF Standard or other standard related to IETF work)".
A BCP isn't a standard, agreed, but publishing a BCP does qualify for being part of "other standard related to IETF work". 

> Furthermore, the actual call for such a reservation appears not to be needed, if we get over the fact that a routed mode + pd is better at handling this case.

As said, if the three IID ranges below are reserved, 464XLAT can be added to nodes that support tethering with /64s without interfering with the chosen approach for this support.
This is IMHO good enough a motivation to just reserve three subranges in a range "available for allocation" in RFC 5342.

This is in my understanding what we are discussing right now.

RD

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 7 Sep 2012 19:47:43 +0200

On 7 September 2012 19:18, Rémi Després <[email-masked]> wrote:

> Let's hope its isn't on purpose, to support an unjustified argument, that
> you truncated the quoted sentence of RFC5342.
> The full sentence is:
> A BCP isn't a standard, agreed, but publishing a BCP does qualify for
> being part of "other standard related to IETF work".
>

"... other standard related to IETF work", means, to me at least: standard
work done outside of the IETF, but related to IETF standards, which would
not appear to apply here.

> As said, if the three IID ranges below are reserved, 464XLAT can be added
> to nodes that support tethering with /64s without interfering with the
> chosen approach for this support.
> This is IMHO good enough a motivation to just reserve three subranges in a
> range "available for allocation" in RFC 5342.
>

Well, it still has "holes". You will get conflicts among devices even if
you reserve a range. The only save way is to stop doing this and assign a
unique /64 for each device, which the routed+pd mode of operation would
accomplish. Given that it is to be supported anyway, it seems like a far
better way than the seeking IANA allocations, etc.

Cheers,
Woj.

---

From: t.petch <[email-masked]>
Date: Fri, 7 Sep 2012 18:53:30 +0100

----- Original Message -----
From: "Rémi Després" <[email-masked]>
To: "Wojciech Dec" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "v6ops WG" <[email-masked]>
Sent: Friday, September 07, 2012 6:18 PM

> Such an assignment is a standards action item, and last I checked we
were not defining a new standard here.

!!!
Let's hope its isn't on purpose, to support an unjustified argument,
that you truncated the quoted sentence of RFC5342.
The full sentence is:
"must be for standards purposes (either for an IETF Standard or other
standard related to IETF work)".
A BCP isn't a standard, agreed, but publishing a BCP does qualify for
being part of "other standard related to IETF work".

<tp>
I think that that qualification is fine; the standing of a BCP does get
called into question at times - does it count as a standard even though
it is not technically on the standards track - but I have not known it
stop an allocation from a registry defined as this one is.  Go back to
the bible of IANA actions, RFC5226, and the magic phrase is 'Standards
Action' - that is what calls for a standards track RFC, nothing else
does.  And that phrase is absent from RFC5342 (guess what it is? yes, a
BCP)
</tp>

As said, if the three IID ranges below are reserved, 464XLAT can be
added to nodes that support tethering with /64s without interfering with
the chosen approach for this support.
This is IMHO good enough a motivation to just reserve three subranges in
a range "available for allocation" in RFC 5342.

<tp>
I can see no reason why this is not a good idea that will work well.  I
express it thus cautiously because I have had one or two surprises along
the way with this work, not so much in the 'wired' environment as in the
'weird' environment (as it sometimes seems to me:-).  So I think we wait
to see if anyone can see an engineering defect therein.

Tom Petch

RD

> Thanks for the clarification about IANA vocabulary (I hadn't checked
www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet-
numbers-4).
>
> With the IANA-related FUD eliminated, and with the common wish to
support /64 delegated prefixes, do you agree that, with the reserved

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 7 Sep 2012 11:11:46 -0700

On Fri, Sep 7, 2012 at 10:47 AM, Wojciech Dec <[email-masked]> wrote:
> Well, it still has "holes". You will get conflicts among devices even if you
> reserve a range. The only save way is to stop doing this and assign a unique
> /64 for each device, which the routed+pd mode of operation would accomplish.
> Given that it is to be supported anyway, it seems like a far better way than
> the seeking IANA allocations, etc.
>
> Cheers,
> Woj.

Woj,

4 points:

1.  The AD (Ron) has already said in the Vancouver meeting that the
IANA request is "Fine".  Let's not go over this again.
http://www.ietf.org/proceedings/84/minutes/minutes-84-v6ops

2.  Sharing the /64 is a clear requirement.  Several people have
stated it is requirement, it will not be given up.

3.  I remain of the opinion that we must just acknowledge the /64
sharing exists and it is for the implementation to determine how best
that must happen.  That said, i am not opposed to reserving the IID
for the sake of enabling a technically astute solution proposed by
Rémi, but maybe that is best for a more general draft  after /64
sharing than 464XLAT I-D.

4. Regarding holes.  I agree, we can corner case this to death if we
try to specify a general solution for all cases, and there is a
serious scope issue.  Hence my point in #3.  Don't solve for all use
cases in all scenarios.  There is no requirement that we have one
universal approach, but we do state DHCP-PD takes priority.

464XLAT defines it self as an architecture in the first sentence, not
a detailed design.

CB

>>> www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet-numbers-4).
>>>

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 7 Sep 2012 20:32:42 +0200

On 7 September 2012 20:11, Cameron Byrne <[email-masked]> wrote:

> added
> you

> universal approach, but we do state DHCP-PD takes priority.

It's a basic case of two clat's on a shared /64 both starting/trying to use
one of the "reserved" addresses. It will fail for one. We could go into
DAD/algorithmic solutions for this problem, but frankly, the solution that
appears to be more sensible is just not to do it and leave this to the PD
mode, rather than standardizing a new way of doing SLAAC (which
coincidentally this appears to be).
This would also allow the design to move directly away from the proxy-nd or
some non-ietf methods (hacks), or nd cache ugliness that we would like to
stay clear of.

-Woj.

> support

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 08:47:41 +0200

2012-09-07 à 20:32, Wojciech Dec :
...

> It's a basic case of two clat's on a shared /64 both starting/trying to use one of the "reserved" addresses. It will fail for one.

As already discussed, this isn't true. 
- Nothing "fails" (as you say), if CLAT addresses WAN side use IIDs in a reserved range, and all hosts are standard-compliant (RFC4291). 
 . CLAT addresses aren't configured on any IPv6-link interface. 
 . Nothing is needed on the LAN side (DAD or otherwise) to prevent CLAT addresses to be used. 
- If some hosts are manually configured with standard-infringing addresses, many failures are indeed possible. But responsibility isn't that of 464XLAT.

If your doubt would remain after checking the above, a detailed example justifying it would be needed to justify it.

RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Sep 2012 17:08:35 +0900

Remi, Cameron, Woj,

I think you're talking past each other here. I believe that what Remi is
proposing is:

0. If the CLAT wants to share its connection to downstream devices, it
SHOULD attempt to obtain a DHCPv6 prefix delegation, but if it has an IPv6
/64, it MAY share that /64 with downstream devices.
1. IANA is requested to reserve three IID ranges for /64 sharing:
  - A 24-bit range to be used to map 10.0.0.0/8
  - A 20-bit range to be used to map 172.16.0.0/12
  - A 16-bit range to be used to map 192.168.0.0/16
2. When translating packets to and from hosts connected to the CLAT's
downstream interface, the CLAT statelessly maps a.b.c.d into
</64>:<iana-resvd>:ab:cd.
3. The CLAT's own IPv6 address is determined by statelessly mapping the
CLAT's downstream private IPv4 address as per point 2.

That way you can only have IPv6 address conflicts only if you have IPv4
address conflicts - in which case you're probably in trouble already.

Of course, this breaks if you put one CLAT behind the other and you have,
for example, 10.0.1.100 in two places in the topology. However, that
scenario is already broken because of the issues detailed in the ND proxy
RFC. I think we can avoid that by saying, additionally:

4. The CLAT MUST NOT share the /64 unless its northbound interface is a
point-to-point interface.

With this scheme, the only real concern I see is excessive use of IID
space. If we're not worried about that, then it seems a good idea to me.

On Mon, Sep 10, 2012 at 3:47 PM, Rémi Després <[email-masked]>wrote:

> > It's a basic case of two clat's on a shared /64 both starting/trying to
> use one of the "reserved" addresses. It will fail for one.
>
> - Nothing "fails" (as you say), if CLAT addresses WAN side use IIDs in a
> reserved range, and all hosts are standard-compliant (RFC4291).
> - If some hosts are manually configured with standard-infringing
> addresses, many failures are indeed possible. But responsibility isn't that
> of 464XLAT.
>
> If your doubt would remain after checking the above, a detailed example
> justifying it would be needed to justify it.
>
> RD
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Sep 2012 18:41:59 +0900

On Sat, Sep 8, 2012 at 12:00 AM, Maoke <[email-masked]> wrote:

> the implemantaion.

I still disagree with this text, because it gives the impression that using
BIH with 464xlat is a best practice, when in fact nobody has even tested it
yet. What about the original suggestion of saying that "464xlat is not
designed to cover the case of IPv4-only applications having access to
IPv6-only servers. If that is needed, another transition mechanism such as
BIH must be employed" ?

By doing so, BIH continue to not be used together with a NAT64, as
> recommended in [RFC6535], while 464xlat is being in charge of using NAT64s
> as PLATs."
>

The way I read that sentence is, "There's a NAT64 in the architecture, and
the BIH packets can go through that NAT64, but we're not using BIH with a
NAT64. We're not because we say we're not. Really." That's pretty bad. We
need to at least say thatif BIH is used, then it SHOULD NOT be used through
the NAT64?

I still don't see why BIH appears in this document at all. There's no
reason to cite it. It's an RFC. People can implement it, deploy it,
whatever - without us having to cite it in this RFC. There are lots of
things you can use with CLAT, like IP-in-UDP-tunneling. But we're not
putting IP-in-UDP-tunneling in this document. Why?

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 12:10:16 +0200

Le 2012-09-10 à 11:41, Lorenzo Colitti a écrit :

> "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers, which will be possibly needed in the future. Together using it with BIH [RFC6535] can be a feasible solution, if this demand becomes true, and we leave the details of the co-existance to the implemantaion.
> 
> I still disagree with this text, because it gives the impression that using BIH with 464xlat is a best practice, when in fact nobody has even tested it yet. What about the original suggestion of saying that "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, another transition mechanism such as BIH must be employed" ?

Support for either of:
(a) "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. Using it together with BIH [RFC6535] can be a feasible solution, and we leave the details of the co-existance to the implementation." (already agreed by Maoke and myself).
(b) "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, another transition mechanism such as BIH must be employed" (your proposal)
(c) "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution." (your proposal, somewhat improved IMHO)

> 
> By doing so, BIH continue to not be used together with a NAT64, as recommended in [RFC6535], while 464xlat is being in charge of using NAT64s as PLATs."
> 
> The way I read that sentence is, "There's a NAT64 in the architecture, and the BIH packets can go through that NAT64, but we're not using BIH with a NAT64. We're not because we say we're not. Really." That's pretty bad. We need to at least say thatif BIH is used, then it SHOULD NOT be used through the NAT64?
> 
> I still don't see why BIH appears in this document at all. There's no reason to cite it. It's an RFC. People can implement it, deploy it, whatever - without us having to cite it in this RFC. There are lots of things you can use with CLAT, like IP-in-UDP-tunneling. But we're not putting IP-in-UDP-tunneling in this document. Why?

Compromise sentences like the above are a way to put an end to this already too long discussion.
If Maoke accepts (b), or if he accepts (c) and you accept it too, we hopefully are done.

RD

---

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 19:26:49 +0900

2012/9/10 Lorenzo Colitti <[email-masked]>

> I still disagree with this text, because it gives the impression that
> using BIH with 464xlat is a best practice, when in fact nobody has even
> tested it yet. What about the original suggestion of saying that "464xlat
> is not designed to cover the case of IPv4-only applications having access
> to IPv6-only servers. If that is needed, another transition mechanism such
> as BIH must be employed" ?
>
>

i share the same feeling. and i support your this suggestion. +1

> need to at least say thatif BIH is used, then it SHOULD NOT be used through

i also doubt there is really not uncertainty to put BIH with CLAT together.
i proposed a case where BIH/CLAT is poorly running for an in-domain
server (which is a naturally established use-case of the CLAT without BIH)
but it is argued this case is out of scope.

so it is sounds to me that people prefer to attach this weird BIH with
CLAT, even sacrifycing the possibly extended scope of usage.

on the other hand, as i have seen that the *combination* is harmful at
least for one case, even it is out of scope, i doubt there is definitely no
in-scope trouble of this putting-together.

a very detailed discussion is here:

1. a host behind the BIH/CLAT is to send out a request to a server, who has
both AAAA and A type resolutions.
2. NOTE BIH is working since the stage of DNS because the host behind is
possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as there
needed double-translation, fine. however, once BIH can get the AAAA type
of the server, it traslates that AAAA to an A type resolution with an IPv4
address under its configuration.
3. then the host possibly receive two A type resolutions: the one of the
genuine A of the server (let's note it as A#1); the one of what is
translated by the BIH (A#2). it might randomly select one to send out the
request.
4. the request arrives at the BIH/CLAT, uncertainty happens:
    - who take over the work? the BIH module or the CLAT module?
    - if it is the BIH, but the host actually selects A#1, then BIH has no
state about this A#1, it has to drop the request;
    - if it is the CLAT module, but it happens that the host choose A#2,
then the CLAT will send the request to nowhere.

i don't know what we still need to make the *combination* of BIH and
464xlat safe in this document.

> putting IP-in-UDP-tunneling in this document. Why?

same view. but they argued that we are newcomers claiming, too late, at
a *trivial* question already *well*-discussed in the WG and the authors
also would like to push the things forward. :( if the above uncertainty is
certain, the working group is making a mistake.

- maoke

---

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 19:42:09 +0900

dear Remi,

please take some time to review the case that i propose in the previous
reply. if you suggest we move forward but leave that case an open
discussion. i suggest a text based on (b) or (c) (almost same to me) and
some of (a):

   464xlat is not designed to cover the case of IPv4-only applications
   having access to IPv6-only servers. If that is needed, BIH [RFC6535]
   possibly provides a solution. This BCP doesn't guarantee the integrity
   of putting 464xlat and BIH together, and we leave the details of the
   co-existance to the implementation.

- maoke
2012/9/10 Rémi Després <[email-masked]>

> (a) "464xlat is not designed to cover the case of IPv4-only applications
> having access to IPv6-only servers. Using it together with BIH [RFC6535]
> can be a feasible solution, and we leave the details of the co-existance to
> the implementation." (already agreed by Maoke and myself).
> (b) "464xlat is not designed to cover the case of IPv4-only applications
> having access to IPv6-only servers. If that is needed, another transition
> mechanism such as BIH must be employed" (your proposal)
> (c) "464xlat is not designed to cover the case of IPv4-only applications
> having access to IPv6-only servers. If that is needed, BIH of [RFC6535]
> provides a solution." (your proposal, somewhat improved IMHO)
>
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 14:09:33 +0200

> i share the same feeling. and i support your this suggestion. +1

+1
(As said in another mail, this sentence is one of those I accept.)

Now that there is an agreement between Lorenzo, you and me.
Let's hope it will be final this time.

RD

---

From: GangChen <[email-masked]>
Date: Mon, 10 Sep 2012 20:12:56 +0800

Hello Lorenzo,

2012/9/10, Lorenzo Colitti <[email-masked]>:
> yet.

We admit the test because that is actually an ongoing work.

>What about the original suggestion of saying that "464xlat is not

I'm not sure what is *another transition mechanism* you indicate. The
fact is we tried to verify that last week. The outcome is that BIH is
the standard track which specified IPv4->IPv6. So it's worth to be
improved like Remi's proposal (c) "464xlat is not designed to cover
the case of IPv4-only applications having access to IPv6-only servers.
If that is needed, BIH of [RFC6535] provides a solution." (your
proposal, somewhat improved IMHO).

> need to at least say thatif BIH is used, then it SHOULD NOT be used through

The statement was already identified in RFC6535. With the reference of
[RFC6535], it gives sufficient information to reader. Not sure we need
to restate that in the 464xlat.

Many thanks

Gang

---

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 21:22:32 +0900

在 2012年9月10日星期一，Rémi Després 写道：

> 2012/9/10 Lorenzo Colitti <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
>
>> On Sat, Sep 8, 2012 at 12:00 AM, Maoke <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
>> > wrote:
>>
>>> my suggestion:
>>>

not yet until you have answered me about the uncertainty just discovered. i
guess you truncated the message too quickly.. - maoke

---

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 21:30:04 +0900

i will raise a thread for that uncertainty when i get home as my text among
the replies was hard to follow. - maoke

在 2012年9月10日星期一，Maoke 写道：

> not yet until you have answered me about the uncertainty just discovered.
> i guess you truncated the message too quickly.. - maoke
>
>
>>
>> RD
>>
>>
>>

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 14:56:29 +0200

Le 2012-09-10 à 14:22, Maoke a écrit :

> not yet until you have answered me about the uncertainty just discovered. i guess you truncated the message too quickly.. - maoke 

Is this to mean that you +1, and support of Lorenzo's suggestion, wasn't real?
If yes that's a disappointment.

I didn't react to your further comments because I felt it wasn't necessary for the conclusion to be acceptable, and I am currently busy on too many subjects. 

This isn't to say I won't react later on but, when you have agreed on a sentence, it would be nice if you wouldn't retract your agreement when someone else agrees too.
Now, BIH is standard track. If 464XLAT would conflict with it, 464XLAT should be modified to avoid that. (Fortunately, this isn't the case.) 

RD

---

From: Tim Chown <[email-masked]>
Date: Mon, 10 Sep 2012 14:24:22 +0100

> I still disagree with this text, because it gives the impression that using BIH with 464xlat is a best practice, when in fact nobody has even tested it yet. What about the original suggestion of sa…

I would only say "another transition mechanism is needed", given this is a BCP text.

> I still don't see why BIH appears in this document at all. There's no reason to cite it. It's an RFC. People can implement it, deploy it, whatever - without us having to cite it in this RFC. There…

I agree with this view.  This document is not aimed at access to v6 servers (and there is big a clue in the name :) so please let's keep it focused to the original problem, which is also stated clearly earlier in the document.

If you want to do a v4-only to v6-only access statement, which in my view should be Informational not BCP, then I would suggest you write a new draft and we can discuss that separately in v6ops.

Tim

---

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 22:25:23 +0900

> If yes that's a disappointment.

i have a modified version. you may see if it is acceptable. on the other
hand, i think you hold the same technical faith as i do that, if we find it
is wrong, even at the last minute, we should correct.

>
> I didn't react to your further comments because I felt it wasn't necessary
> for the conclusion to be acceptable, and I am currently busy on too many
> subjects.
>
>

i see this displomatic, sorry. but i can understand you are busy.

>
> This isn't to say I won't react later on but, when you have agreed on a
> sentence, it would be nice if you wouldn't retract your agreement when
> someone else agrees too.
>
>

i still agree that sentence but i think that is not yet comprehensive
enough. see my suggested modification.

>
> Now, BIH is standard track. If 464XLAT would conflict with it, 464XLAT
> should be modified to avoid that. (Fortunately, this isn't the case.)
>
>

i argued that 464xlat should be running independently. BIH cannot be
running together with 464xlat is not the fault of the original 464xlat.
don't cut feet to fit the shoes. are you suggest me to insist adding a text
stating: NOT TO USE BIH with 464xlat?

- maoke

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 10 Sep 2012 15:38:50 +0200

Hi Lorenzo,

On 10 September 2012 10:08, Lorenzo Colitti <[email-masked]> wrote:

> /64, it MAY share that /64 with
>
downstream devices.

Well, the sharing I am thinking of are further subtended IPv6 devices,
possibly clats and this is where the "sharing" of the /64 downstream gets
messy as in "it requires ND tricks, or hacks". It is the same case for a
shared link really.

> point-to-point interface.

Right, but on a point-point link, one doesn't need the reserved IANA range
anyway. That /64 is there for the device, and it can map anything into the
IID, and strictly speaking it doesn't need to be limited to the ranges
above.

So in summary, as far as I see it is as follows:
- If we're covering the p2p link case and subtended IPv4 devices, a single
/64 is enough and no need of IANA assignments. Whatever the hosts will use
is determined by the DHCPv4 assignment the clat device will (presumably)
give.
- If we're talking about subtended IPv6 devices and sharing a /64, then the
IANA assignment lead to ND hacks, some new form of SLAAC; best left for
handling via DHCP PD.

Regards,
Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 10 Sep 2012 15:40:39 +0200

+1

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 16:02:03 +0200

Le 2012-09-10 à 15:25, Maoke a écrit :

>>> ... What about the original suggestion of saying that "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, another transition mechanism such as BIH must be employed" ?
>>>  
>>>  
> i have a modified version. you may see if it is acceptable. on the other hand, i think you hold the same technical faith as i do that, if we find it is wrong, even at the last minute, we should correct.

(*)
Sorry, I am lost.
Which is the sentence you now accept?

(And I am disappointed to discover that, in the same mail, you expressed an agreement and had further text which, you later said, needs resolution before your agreement is valid.)

> i see this displomatic, sorry. but i can understand you are busy.

It wasn't diplomatic.
I was really hoping not to study the very detailed example you have documented for Lorenzo.

> i still agree that sentence but i think that is not yet comprehensive enough. see my suggested modification.

Which one?
(see (*) above)

> i argued that 464xlat should be running independently. BIH cannot be running together with 464xlat is not the fault of the original 464xlat. don't cut feet to fit the shoes. are you suggest me to insist adding a text stating: NOT TO USE BIH with 464xlat?

Yes, they "should be running independently".
It is FALSE that BIH cannot run together with 464XLAT. (I will soon comment the example you provided as a reason for FUD against this running together). 
I wish I hadn't seen the last sentence.

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 16:06:01 +0200

Maoke,

After your insisting that I comment the detailed example below you had addressed to lorenzo, let me do it first priority, for the sake of 464XLAT quick progress.

Your example has an IPv4-only host that is supposed to get a public A record and another A record that would be derived from  a AAAA by a BIH.
This isn't AFAIK a realistic scenario for at least the following reasons:
(1) BIH address mapping doesn't apply when both AAAA and A records are received and the A address in not an excluded one (section 2.4 of RFC6535).
(2) BIH is only for applications that are in the BIH node itself. As such, it must not forward AAAA-derived IPv4 addresses to any other node. (These addresses are taken in a private address pool).

RD

Le 2012-09-10 à 12:26, Maoke a écrit :

> i also doubt there is really not uncertainty to put BIH with CLAT together. i proposed a case where BIH/CLAT is poorly running for an in-domain server (which is a naturally established use-case of the CLAT without BIH) but it is argued this case is out of scope.
>  
> so it is sounds to me that people prefer to attach this weird BIH with CLAT, even sacrifycing the possibly extended scope of usage.
>  
> on the other hand, as i have seen that the *combination* is harmful at least for one case, even it is out of scope, i doubt there is definitely no in-scope trouble of this putting-together.
>  
> 1. a host behind the BIH/CLAT is to send out a request to a server, who has both AAAA and A type resolutions.  
> 2. NOTE BIH is working since the stage of DNS because the host behind is possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as there needed double-translation, fine. however, once BIH can get the AAAA type of the server, it traslates that AAAA to an A type resolution with an IPv4 address under its configuration.
> 3. then the host possibly receive two A type resolutions: the one of the genuine A of the server (let's note it as A#1); the one of what is translated by the BIH (A#2). it might randomly select one to send out the request.
>     - if it is the BIH, but the host actually selects A#1, then BIH has no state about this A#1, it has to drop the request;
>     - if it is the CLAT module, but it happens that the host choose A#2, then the CLAT will send the request to nowhere.  
>  
> i don't know what we still need to make the *combination* of BIH and 464xlat safe in this document.
>  
>  
> same view. but they argued that we are newcomers claiming, too late, at a *trivial* question already *well*-discussed in the WG and the authors also would like to push the things forward. :( if the above uncertainty is certain, the working group is making a mistake.
>  
> - maoke

---

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 23:29:22 +0900

> Maoke,
>
> After your insisting that I comment the detailed example below you had
> addressed to lorenzo, let me do it first priority, for the sake of 464XLAT
> quick progress.
>
>

i reply Lorenzo but cc to the WG and i suppose that the text that i would
like to share to all. thanks a lot for taking it in priority.

>
>
> Your example has an IPv4-only host that is supposed to get a public A
> record and another A record that would be derived from  a AAAA by a BIH.
> (1) BIH address mapping doesn't apply when both AAAA and A records are
> received and the A address in not an excluded one (section 2.4 of RFC6535).
>
>

thanks for the link of the text. i didn't notice that. but this only
prevents CLAT sending things to A#2. what if the packet is delivered to the
BIH module?

actually the missing part is, when we are talking "combining" two things,
we should at least specify they are working parallel, selected by the path
decision mechanism, or serially. if parallel, how to select the path; if
serial, who is in front who is behind?

>
> (2) BIH is only for applications that are in the BIH node itself. As such,
> it must not forward AAAA-derived IPv4 addresses to any other node. (These
> addresses are taken in a private address pool).
>
>

confusing to me. CLAT is able to work for a subnet where the hosts are.
what the applications does the BIH/CLAT box itself have in the 464xlat
architecture.

and according to the discussion linked by Gang to me, there was the
discussion that people said the BIH was not designed for forwarding but
replies stated it was able to do so.

- maoke

>> The way I read that sentence is, "There's a NAT64 in the architecture,
>> and the BIH packets can go through that NAT64, but we're not using BIH with
>> a NAT64. We're not because we say we're not. Really." That's pretty bad. We
> i also doubt there is really not uncertainty to put BIH with CLAT
> together. i proposed a case where BIH/CLAT is poorly running for an
> in-domain server (which is a naturally established use-case of the CLAT
> without BIH) but it is argued this case is out of scope.
>

---

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 23:36:53 +0900

2012/9/10 Maoke <[email-masked]>

> prevents CLAT sending things to A#2. what if the packet is delivered to the

i mean: what if the packet with destination A#1 has been delivered to BIH
module? - maoke

>> (2) BIH is only for applications that are in the BIH node itself. As
>> such, it must not forward AAAA-derived IPv4 addresses to any other node.
>> (These addresses are taken in a private address pool).
>>
>>
>
>>     - if it is the BIH, but the host actually selects A#1, then BIH has
>> no state about this A#1, it has to drop the request;

---

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 23:42:20 +0900

>>>> ... What about the original suggestion of saying that "464xlat is not

well. sorry for the confusion. i has clarified my concern and suggested
text in a separated thread. - maoke

>
>
> (And I am disappointed to discover that, in the same mail, you expressed
> an agreement and had further text which, you later said, needs resolution
> before your agreement is valid.)
>
>
>
> It is FALSE that BIH cannot run together with 464XLAT. (I will soon
> comment the example you provided as a reason for FUD against this running
> together).

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 16:59:15 +0200

2012-09-10 16:42, Maoke :
...
> well. sorry for the confusion. i has clarified my concern and suggested text in a separated thread. - maoke

Still lost.
Which sentence, on which thread?

Thanks,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 17:24:22 +0200

2012-09-10 16:29, Maoke :

> i reply Lorenzo but cc to the WG and i suppose that the text that i would like to share to all. thanks a lot for taking it in priority.
>  
>  
> 
> thanks for the link of the text. i didn't notice that. but this only prevents CLAT sending things to A#2. what if the packet is delivered to the BIH module?

BIH doesn't apply AT ALL when both an A and a AAAA are received for a server.
Your example being AFAIK in this case, no conflict between BIH and anything else can exist. 

>  
> actually the missing part is, when we are talking "combining" two things, we should at least specify they are working parallel, selected by the path decision mechanism, or serially. if parallel, how to select the path; if serial, who is in front who is behind?

464XLAT applies to reach public IPv4 addresses, and BIH to reach servers that have no public IPv4 address.
The order in which their applicability is tested is therefore irrelevant.

> confusing to me. CLAT is able to work for a subnet where the hosts are. what the applications does the BIH/CLAT box itself have in the 464xlat architecture.

Let's leave this aside, at least for the time being, the point above being sufficient (if you authorize me to work withy high priority only on points that condition decisions to be made ;-))
 
>  
> and according to the discussion linked by Gang to me, there was the discussion that people said the BIH was not designed for forwarding but replies stated it was able to do so.

Can we please limit this discussion about what BIH does to what there is in the RFC itself (at least in a first step, which hopefully will be sufficient).

RD

---

From: Maoke <[email-masked]>
Date: Tue, 11 Sep 2012 00:34:44 +0900

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

> that have no public IPv4 address.

the first DNS request is taken by BIH or by 464xlat? it is highly possible
to be 464xlat, no matter the result is A or AAAA, right? how the BIH can
get the information about that AAAA and/or A? the path seems to me has no
business with the BIH though.

if i missed anything, please specify further. it is fine to me that the
below is left aside.

- maoke

> Let's leave this aside, at least for the time being, the point above being
> sufficient (if you authorize me to work withy high priority only on points
> that condition decisions to be made ;-))
>
>
>
> Can we please limit this discussion about what BIH does to what there is
> in the RFC itself (at least in a first step, which hopefully will be
> sufficient).
>
> RD
>
>
>

---

From: GangChen <[email-masked]>
Date: Mon, 10 Sep 2012 23:35:41 +0800

> prevents CLAT sending things to A#2. what if the packet is delivered to the

The packet with destination A#1 would naturally not be processed by
BIH, because destination A#1 can't match any item in BIH mapping
table.

>> such,

I hope that is not on-purpose. If that isn't clear to you, I could
restate the answers to you. BIH is doing the work only for IPv4
APPLICATION. There is nothing to do with tethered IPv4 HOSTs. In the
previous discussion, you are talking about CLAT-CLAT case, which is
identified as out of the scope.

Gang

>> no

---

From: Maoke <[email-masked]>
Date: Tue, 11 Sep 2012 00:37:10 +0900

2012/9/11 GangChen <[email-masked]>

> identified as out of the scope.

in current discussion it is not about CLAT-CLAT and it is in scope. - maoke

> >>>> future. Together using it with BIH [RFC6535] can be a feasible
> solution,
> >>>> if
> >>> a NAT64. We're not because we say we're not. Really." That's pretty
> bad.
> >>> We

---

From: GangChen <[email-masked]>
Date: Mon, 10 Sep 2012 23:43:36 +0800

> in current discussion it is not about CLAT-CLAT and it is in scope. - maoke

Given you know there are differences, why do you point the previous
discussion and intentionally mix it. If you like the mess, please
Don't DO that here.

>> >>>> this demand becomes true, and we leave the details of the
>> >>>> co-existance
>> >>>> to
>> >>>> the implemantaion.
>> >>>>
>> >>>
>> >>> and the BIH packets can go through that NAT64, but we're not using
>> >>> BIH
>> >>> with
>> >> least for one case, even it is out of scope, i doubt there is
>> >> definitely
>> >> no
>> >> 1. a host behind the BIH/CLAT is to send out a request to a server,
>> >> who
>> >> has both AAAA and A type resolutions.
>> >> also would like to push the things forward. :( if the above
>> >> uncertainty
>> >> is

---

From: Maoke <[email-masked]>
Date: Tue, 11 Sep 2012 00:50:40 +0900

> discussion and intentionally mix it. If you like the mess, please

sorry but i don't comment on this "intentionally mix it" and "mess". out of
scope of the technical discussion. - maoke

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 18:01:08 +0200

Le 2012-09-10 à 17:34, Maoke a écrit :

> the first DNS request is taken by BIH or by 464xlat? it is highly possible to be 464xlat, no matter the result is A or AAAA, right? how the BIH can get the information about that AAAA and/or A? the path seems to me has no business with the BIH though.

A DNS request from an IPv4-only host has, as you say, "no business with the BIH" (like any packet from such a host to a public IPv4 address).

> if i missed anything, please specify further. it is fine to me that the below is left aside.

Unless I miss something, this puts an end of the technical concern that 464XLAT and BIH might not gracefully coexist. 
Preferred sentence is then:
"464XLAT is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution."

Acceptable?
RD

---

From: Maoke <[email-masked]>
Date: Tue, 11 Sep 2012 01:22:50 +0900

> A DNS request from an IPv4-only host has, as you say, "no business with
> the BIH" (like any packet from such a host to a public IPv4 address).
>
>

not only that. then the IPv4 host may possibly get a AAAA-type reply from
the DNS system (surely an IPv4 DNS server can reply AAAA-type for a
request). then the reply will be sent by the IPv4 DNS server (through PLAT
and CLAT) to the host, right? there's no business of BIH even if the target
server is IPv6-only.

and therefore the IPv4-only host, getting the AAAA stuff, can do nothing
with it. only when the BIH stands between the IPv4-only host and the CLAT,
it is possible that the BIH hijack the AAAA reply and synthesize a A reply
for the host.

but there should be a dilemma in such a serial workflow: if there is the
genuine A reply, BIH module needs to transparently deliver that to the host
and accepts the further packets from the host and transparently forward
that to the CLAT module. does BIH work as a transparent router to genuine
IPv4 destinations? (i don't understand RFC6535 saying so but need to
confirm)

> Unless I miss something, this puts an end of the technical concern that
> 464XLAT and BIH might not gracefully coexist.
> "464XLAT is not designed to cover the case of IPv4-only applications
> provides a solution."

i prefer Tim's suggestion not to mention any specific protocol here but
only
     "... If that is needed, another transition mechanism should be
considered".

if we are definitely to cite the BIH explicitly here, i think we are
obliged to state:
     "This BCP doesn't guarantee that they are gracefully working
together while leave the co-existance details as an open issue."

- maoke

>> Let's leave this aside, at least for the time being, the point above
>> being sufficient (if you authorize me to work withy high priority only on
>> points that condition decisions to be made ;-))
>>
>>
>>

---

From: GangChen <[email-masked]>
Date: Tue, 11 Sep 2012 00:44:58 +0800

> it is possible that the BIH hijack the AAAA reply and synthesize a A reply

Wait... you are intending to change the behavior of RFC6535 according
to your imagination. Can I ask you to re-read the 464xlat and RFC6535?
Otherwise, I can see nothing we could achieve through the discussion.

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 18:48:07 +0200

Le 2012-09-10 à 18:22, Maoke a écrit :

> not only that. then the IPv4 host may possibly get a AAAA-type reply from the DNS system (surely an IPv4 DNS server can reply AAAA-type for a request). then the reply will be sent by the IPv4 DNS server (through PLAT and CLAT) to the host, right? there's no business of BIH even if the target server is IPv6-only.
>  
> and therefore the IPv4-only host, getting the AAAA stuff, can do nothing with it. only when the BIH stands between the IPv4-only host and the CLAT, it is possible that the BIH hijack the AAAA reply and synthesize a A reply for the host.
>  
> but there should be a dilemma in such a serial workflow: if there is the genuine A reply, BIH module needs to transparently deliver that to the host and accepts the further packets from the host and transparently forward that to the CLAT module. does BIH work as a transparent router to genuine IPv4 destinations? (i don't understand RFC6535 saying so but need to confirm)
>  
>  
> 
> 
> i prefer Tim's suggestion not to mention any specific protocol here but only
>      "... If that is needed, another transition mechanism should be considered". 

You say you "prefer" this other wording (which hides useful information) but, in view of your next sentence below, you even refuse the wording that you don't prefer!

Frankly, this is one more disappointment after so much effort to teach you what BIH does.

> if we are definitely to cite the BIH explicitly here, i think we are obliged to state:
>      "This BCP doesn't guarantee that they are gracefully working together while leave the co-existance details as an open issue."

There is absolutely no justification for such a negative sentence!
- If you no reason is identified why 464XLAT and BIH wouldn't gracefully coexist, suggesting one exists is unacceptable.
- Especially since 
 . Some others who have carefully studied both 464XLAT and BIH for quite some time have found no reason to doubt. 
 . One an implementation is in progress.
 . All your past reasons to doubt have been answered.

So, let me ask again whether you can consider the following sentence as ACCEPTABLE?
"464XLKAT is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution."

RD

---

From: Gert Doering <[email-masked]>
Date: Mon, 10 Sep 2012 20:02:31 +0200

Hi,

> it is possible that the BIH hijack the AAAA reply and synthesize a A reply

What, exactly, does this have to do with the draft at hand?

There are no IPv*4*-only hosts here.  There's an IPv6-only host, which
can do IPv4 by help of 464xlat.  So BIH does not apply at all.

I really wonder if this is getting anywhere - as soon as one crazy reason
why this draft can not proceed has been silenced with 200+ e-mails, the
next one springs up.

Could people please focus on this draft, and not on "what other byzantine
migration schemes might exist or not, and might want to be mentioned or
should not mentioned in this draft"?

I already deleted about a 100 unread mails in this thread today, because
some of us really have work to do.

Gert Doering
        -- IPv6 Operator, hoping to see IPv6 deployment in mobile networks,
           and *this* is an important piece.
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Maoke <[email-masked]>
Date: Tue, 11 Sep 2012 07:20:31 +0900

2012/9/11 Gert Doering <[email-masked]>

> can do IPv4 by help of 464xlat.  So BIH does not apply at all.

the current version have this

      +--------+-------------+-----------------------+-------------+
        | Server | Application |   Traffic Treatment   | Location of |
        |        | and Host    |                       | Translation |
        +--------+-------------+-----------------------+-------------+
        |  IPv6  |    IPv6     |    End-to-end IPv6    |    None     |
        +--------+-------------+-----------------------+-------------+
        |  IPv4  |    IPv6     | Stateful Translation  |    PLAT     |
        +--------+-------------+-----------------------+-------------+
        |  IPv4  |    IPv4     |        464XLAT        |  PLAT/CLAT  |
        +--------+-------------+-----------------------+-------------+
        |  IPv6  |    IPv4     |          BIH          |    CLAT     |
        +--------+-------------+-----------------------+-------------+

for the last line, i just want to identify how the work is done since the
very beginning, i.e. the DNS resolution.

if you mean: when BIH is applied, it is ONLY the case that the CLAT is
playing as a host rather than the router for a subnet, then i may finalize.
the following words are none of my business, sorry.

- maoke

---

From: Maoke <[email-masked]>
Date: Tue, 11 Sep 2012 07:32:39 +0900

>>> i reply Lorenzo but cc to the WG and i suppose that the text that i
>>> would like to share to all. thanks a lot for taking it in priority.
>>>
>>>
>>>>
>>>>
>>> actually the missing part is, when we are talking "combining" two
>>> things, we should at least specify they are working parallel, selected by
>>> the path decision mechanism, or serially. if parallel, how to select the
>>> path; if serial, who is in front who is behind?
>>>
>>>
>> the first DNS request is taken by BIH or by 464xlat? it is highly
>> possible to be 464xlat, no matter the result is A or AAAA, right? how the
>> BIH can get the information about that AAAA and/or A? the path seems to me
>> has no business with the BIH though.
>>
>>
dear Remi, is it hard for you to teach me a little more about the above
rather than asking me "acceptable"? if you think this is trivial, please do
it offline. i really want to know.

i don't care about the draft wording anymore. i don't think all the RFC are
good in the same quality in the history -- it is acceptable. had i
not noticed the problem the WG would have processed it. if others are
silent, i don't need to make things difficult for everyone. or you may
totally ignore my *noise*.

okay. though you are very busy, i make the deal: you promise to teach
me about the above behavior offline; i stop my objection no matter
what i get to understand through the education. acceptable?

- maoke

> You say you "prefer" this other wording (which hides useful information)
> but, in view of your next sentence below, you even refuse the wording that
> you don't prefer!
>
> - If you no reason is identified why 464XLAT and BIH wouldn't gracefully
> coexist, suggesting one exists is unacceptable.
> - Especially since
> "464XLKAT is not designed to cover the case of IPv4-only applications

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Sep 2012 13:29:28 +0900

On Mon, Sep 10, 2012 at 10:38 PM, Wojciech Dec <[email-masked]> wrote:

> - If we're talking about subtended IPv6 devices and sharing a /64, then
> the IANA assignment lead to ND hacks, some new form of SLAAC; best left for
> handling via DHCP PD.
>

Not sure I agree with this last point, because I'm not sure what you
mean. I assert that the following scenario:

   - CLAT with only one public IPv6 /64
   - With a p2p northbound interface and a broadcast downstream interface
   - Sharing the /64 to directly connected downstream clients

Can be done robustly, with no ND proxy hacks at all (with or without IANA
assignment). Do you agree?

I agree that IPv6 more than one level deep, (e.g., with cascading CLATs),
cannot be done without hacks, and that these hacks don't really work. For
this situation we must require DHCPv6 PD.

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Sep 2012 07:44:40 +0100

> some of us really have work to do.

This. 

Please do not add a reference to BIH or any other similar solution to a document that is a BCP addressing a completely different problem.

If you want to consider BIH's applicability to different problem then write an Informational draft on BIH in this context.

Tim

---

From: GangChen <[email-masked]>
Date: Tue, 11 Sep 2012 15:22:10 +0800

Hello Tim,

2012/9/11, Tim Chown <[email-masked]>:
> Please do not add a reference to BIH or any other similar solution to a
> document that is a BCP addressing a completely different problem.

I can't agree with your arguments.
There are not only discussions of 100+ mails, but dedicated
implementation efforts.
It doesn't make sense to ignore people's efforts that make the
solution more complete without any identified issues.

> If you want to consider BIH's applicability to different problem then write
> an Informational draft on BIH in this context.

BIH didn't apply to different problem, which is already clarified with
current proposal *464XLKAT is not designed to cover the case of
IPv4-only applications having access to IPv6-only servers. If that is
needed, BIH of [RFC6535] provides a solution.*
BIH is indeed qualified to the context statement and already justified
in RFC6535, no informational part needed IMHO.

BRs

Gang

---

From: Maoke <[email-masked]>
Date: Tue, 11 Sep 2012 16:44:12 +0900

> needed, BIH of [RFC6535] provides a solution.*

i am still waiting for your and Remi's offline discussion as the condition
to accept the proposed text. i won't object anymore if you just do the
offline discussion. if you don't, sorry, seeing "already clarified" is not
yet qualified for the time being. - maoke

---

From: Rémi Després <[email-masked]>
Date: Tue, 11 Sep 2012 09:55:29 +0200

2012-09-11 06:29, Lorenzo Colitti :

> - If we're talking about subtended IPv6 devices and sharing a /64, then the IANA assignment lead to ND hacks, some new form of SLAAC; best left for handling via DHCP PD.
> 
> Not sure I agree with this last point, because I'm not sure what you mean. I assert that the following scenario:
> CLAT with only one public IPv6 /64
> With a p2p northbound interface and a broadcast downstream interface
> Sharing the /64 to directly connected downstream clients
> Can be done robustly, with no ND proxy hacks at all (with or without IANA assignment). Do you agree?

Without IANA registered assignment, a link has to be created between DAD and CLAT modules, in order to exclude on the LAN addresses used by the CLAT.
This isn't necessary with CLAT-resreved IID ranges.
Anything missed?

> 
> I agree that IPv6 more than one level deep, (e.g., with cascading CLATs), cannot be done without hacks, and that these hacks don't really work. For this situation we must require DHCPv6 PD.

With only a /64, cascading prefix delegations isn't possible, an therefore cascading CLATs.
Anything missed?

RD

---

From: GangChen <[email-masked]>
Date: Tue, 11 Sep 2012 16:01:13 +0800

Hello Maoke,

> yet qualified for the time being. - maoke

The concerns you raised have been addressed. Given there are intensive
discussions, I'm not sure what we should discuss offline. But if you
insist, I can help to make that happened .

BRs

Gang

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Sep 2012 17:21:36 +0900

On Tue, Sep 11, 2012 at 3:44 PM, Tim Chown <[email-masked]> wrote:

> If you want to consider BIH's applicability to different problem then
> write an Informational draft on BIH in this context.
>

Amen.

---

From: Rémi Després <[email-masked]>
Date: Tue, 11 Sep 2012 10:27:46 +0200

Hi, Tim,

A complaint just arrived that the past discussion on 464XLAT and BIH has been too long. Fair enough, but it was with serious technical considerations, and among seriously involved participants. 
Now, at a time when these participants seem to reach conclusion, Gert and yourself come in to restart the discussion!

Th latest version of the proposed sentence is "464XLKAT is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution":
- It is true
- It expresses that, contrary to some doubts recently expressed, there is no contradiction between 464XLAT and BIH (RFC 6536 on BIH is little known, but does exist on standard-track).
- It is a correction of a wrong statement of draft-00 suggesting that, with 464XLAT, "it is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts".
- It is an improved version of a sentence which has been in the draft for quite some time. 

Expressing NOW objections to the result of the discussion amounts to restarting this discussion.
Is this really what you wish?

Hoping you can accept whatever participants to the long discussion have agreed on,
Regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Sep 2012 17:31:42 +0900

> Is this really what you wish?

I think if you read his email carefully, you'll conclude that what he would
like to see is: a) the discussion stops, b) the reference to BIH is taken
out, and c) we move on. I agree.

---

From: GangChen <[email-masked]>
Date: Tue, 11 Sep 2012 16:40:44 +0800

Hello Lerenzo,

If the rough consensus should be respected, if the past discussions
should be respected, if some implementation efforts should be
respected, I hope you conclude a) the discussion stops, b) take
current proposal, and c) we move on.

BRs

Gang

---

From: Gert Doering <[email-masked]>
Date: Tue, 11 Sep 2012 10:41:18 +0200

Hi,

> Hoping you can accept whatever participants to the long discussion have agreed on,

I seem to have missed that anyone agreed on anything.  It was certainly
not clear to me from the mail I commented on that agreement was near.

If you are in agreement, all the better, this document is needed.

Gert Doering
        -- NetMaster

---

From: Maoke <[email-masked]>
Date: Tue, 11 Sep 2012 17:41:39 +0900

dear Gang, Remi, Lorenzo and all,

hereby, as Remi has accept the offline discussion  (and thanks to Gang and
Lorenzo who are also doing so), i must keep my promise to stop my objection
here. sorry that i occupied a lot of the WG time but only for my own
understanding. try to do this offline now.

my answer to Remi's question is: yes, it is acceptable for me to state
""464XLAT is not designed to cover the case of IPv4-only applications
having access to IPv6-only servers. If that is needed, BIH of [RFC6535]
provides a solution." (typo is corrected)

- maoke

> >> write

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Sep 2012 17:49:36 +0900

> current proposal, and c) we move on.

I don't see rough consensus. It seems to me that you and Remi want BIH to
be mentioned, Maoke does not, I prefer not, and Gert and Tim don't want it
to be mentioned. Where is the consensus there?

---

From: GangChen <[email-masked]>
Date: Tue, 11 Sep 2012 17:02:32 +0800

> to be mentioned. Where is the consensus there?

I saw the consensus, because
1) It has been documented in current draft and confirmed through
several versions
2) Authors acknowledged that and think that is a complementary part to
the draft
3) The intention have been thoroughly discussed on the list, no issues
identified

If you claim there is no consensus so far on this thread, that is another story

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Tue, 11 Sep 2012 11:02:51 +0200

2012-09-11 10:31, Lorenzo Colitti :

> On Tue, Sep 11, 2012 at 5:27 PM, Rémi Després <[email-masked]> wrote:
> I think if you read his email carefully, you'll conclude that what he would like to see is: a) the discussion stops, b) the reference to BIH is taken out, and c) we move on. I agree.

I did read his email carefully, and did understand it.
Your several-times expressed _preference_ for deleting the sentence has also been well understood. 

But we recently had, in this long discussion, sentences acceptable by both of us, by Gang, and _almost_ by Maoke. The best candidate (mentioned in my mail to Tim) is:
"464XLKAT is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution"

Maoke's concerns are now being resolved as:
- he said today "i make the deal: you promise to teach me about the above behavior offline; i stop my objection no matter what i get to understand through the education".
- I did may part of the deal.

Hope we can conclude on this... and move on.

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 11 Sep 2012 11:33:22 +0200

Dear authors of the 464XLAT draft,

The compromise now reached, among active participants of a long discussion on the relation between 464XLAT and BIH, is the following:
"464XLAT is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution."

Unless the discussion is restarted, it can replace the current wording  of the draft.

Thanks, and best regards,
RD

> De : Maoke <[email-masked]>
> Date : 2012-09-11 10:41
> À : GangChen <[email-masked]>, Rémi Després <[email-masked]>
> Cc : v6ops WG <[email-masked]>
> Objet : Rép : [v6ops] draft-ietf-v6ops-464xlat WGLC
> 
> 
> hereby, as Remi has accept the offline discussion  (and thanks to Gang and Lorenzo who are also doing so), i must keep my promise to stop my objection here. sorry that i occupied a lot of the WG time but only for my own understanding. try to do this offline now.
>  
> my answer to Remi's question is: yes, it is acceptable for me to state ""464XLAT is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution." (typo is corrected)
>  
> - maoke 
...

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Sep 2012 18:39:16 +0900

On Tue, Sep 11, 2012 at 6:33 PM, Rémi Després <[email-masked]>wrote:

> The compromise now reached, among active participants of a long discussion
> on the relation between 464XLAT and BIH, is the following:

I don't see why we need this text at all.

I don't think "restarting the discussion" is going to help convince me, I
think it's more likely that it will only alienate the people who don't care.

Obviously, since proceeding only requies rough consensus, not unanimity,
the WG is free to ignore my opinion if it is not shared by others.

---

From: t.petch <[email-masked]>
Date: Tue, 11 Sep 2012 11:41:23 +0100

----- Original Message -----
From: "Lorenzo Colitti" <[email-masked]>
To: "GangChen" <[email-masked]>
Cc: "v6ops WG" <[email-masked]>
Sent: Tuesday, September 11, 2012 9:49 AM
> to be mentioned. Where is the consensus there?

In the hope that it may help those responsible for judging consensus, I
too would be happy to see BIH removed altogether.

I note that Cameron was also of this view on the 8th May, albeit a few
thousand e-mails ago.

Tom Petch

---

From: GangChen <[email-masked]>
Date: Tue, 11 Sep 2012 19:50:45 +0800

Hello Tom,

> I note that Cameron was also of this view on the 8th May, albeit a few

As you noted, that was the situation long-time before.
The past discussions help to achieve the consensus which was
documented in the draft.
For what I can see, Cameron claimed the position in
http://www.ietf.org/mail-archive/web/v6ops/current/msg14176.html
several days ago

Just claming the appeal and length discussion without justification
really doesn't benefit everybody's timing here as mentioned in the
list

BRs

Gang

---

From: Tom Taylor <[email-masked]>
Date: Tue, 11 Sep 2012 08:49:38 -0400

So do I.

Rémi, truth is a necessary but not a sufficient condition for relevance. 
And sheer persistence does not demonstrate consensus.

Tom T.

On 11/09/2012 4:31 AM, Lorenzo Colitti wrote:
> On Tue, Sep 11, 2012 at 5:27 PM, Rémi Després <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> I think if you read his email carefully, you'll conclude that what he
> would like to see is: a) the discussion stops, b) the reference to BIH
> is taken out, and c) we move on. I agree.
>
>

---

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

> I note that Cameron was also of this view on the 8th May, albeit a few

Lorenzo has indeed been clear that he didn't favor any statement about BIH, but he also has expressed openness to keeping one. (See "if you don't want to remove BIH, then please suggest text to address this issue..." at least at the end of /www.ietf.org/mail-archive/web/v6ops/current/msg14159.html)

Since the detailed discussion has finally clarified that there is nothing contentious in the proposed statement, I think there is no need to refuse the compromise, and no need to restart a debate as though it hadn't already taken place.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 11 Sep 2012 15:19:54 +0200

2012-09-11 à 14:49, Tom Taylor :

> So do I.
> 
> Rémi, truth is a necessary but not a sufficient condition for relevance. And sheer persistence does not demonstrate consensus.

Tim: No need to explain what I have know for years ;-).

As said about the sentence that mentions complementarity of 4X4XLAT and BIH, in particular in www.ietf.org/mail-archive/web/v6ops/current/msg14244.html:
- It is true
- It expresses that, contrary to some doubts recently expressed, there is no contradiction between 464XLAT and BIH (RFC 6536 on BIH is little known, but does exist on standard-track).
- It is a correction of a wrong statement of draft-00 suggesting that, with 464XLAT, "it is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts".
- It is an improved version of a sentence which has been in the draft for quite some time. 

Objections to this sentence are essentially based on "we don't care, and would be happy if those who care would stop doing it".

Hope it helps to move on without restarting a long debate.

RD

---

From: t.petch <[email-masked]>
Date: Tue, 11 Sep 2012 18:19:39 +0100

----- Original Message -----
From: "GangChen" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Lorenzo Colitti" <[email-masked]>; "v6ops WG" <[email-masked]>
Sent: Tuesday, September 11, 2012 12:50 PM
> >> I don't see rough consensus. It seems to me that you and Remi want
BIH
> The past discussions help to achieve the consensus which was

May is not that long ago, and it is a concern of mine just how many
twists and turns there have been in the course of this year, of changes
to solution, scenario and so on.  That suggests to me that there is
something wrong here, even if I cannot put my finger on it more
precisely.

On BIH in particular, I would expect a BIH memo to say what it has to
say about itself, I fail to see why a 464XLAT memo should refer to it at
all, a point which has been made on a number of occasions on this list.
As to where the consensus lies on such a point, I leave that to others
more expert in judging such matters than I to decide.

Tom Petch

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Sep 2012 20:57:21 +0100

> Is this really what you wish?

Hi Remi,

The WGLC invites comments, and thus some of us have made such comments against adding a reference to BIH in this BCP document. You yourself say above it's a 'future case', and it's not one that I believe was originally targeted by the text, hence my suggestion for a separate Informational document on its use for IPv6-only servers.

I have no significant issues with the rest of the text, which I think is a useful document.

Tim

---

From: GangChen <[email-masked]>
Date: Wed, 12 Sep 2012 15:10:26 +0800

> all, a point which has been made on a number of occasions on this list.

Leaving aside the particular 464 context, the same goal (i.e.
advancing IPv6-only deployment) is targeted by BIH and 464xlat. The
past discussion helps us to identify the complementary relationship
between those two. Ongoing efforts are dedicatedly expended under such
guidance. That is the significance of *mentioned* texts. At this
stage, I can't accept removing the texts just because some
observations of "twists and turns". You could even help to identify
the particular concerns that prevent those two from cooperation. That
even is of value to teach people there is a lesson "don't do such
combining thing". However, ignoring the fact without justifications
and silence about the combination is irresponsible to the ongoing
efforts and potential efforts of others.

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Sep 2012 10:27:34 +0200

> The WGLC invites comments, and thus some of us have made such comments against adding a reference to BIH in this BCP document. You yourself say above it's a 'future case', and it's not one that I b…

1. I would personally have preferred to avoid words such as "in the future case" but, in a sense of compromise with views expressed by others, in particular by Brian Carpenter on this ML, I confirm I can _accept_ them. The important fact that remains is that BIH is specified in an existing standard-track RFC. Checking compatibility with it therefore makes sense even if deployments may all be in the future (which I don't know).

2. Contrary to your belief, this case WAS "originally targeted by the text". Introduction of version -00 had "it is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts". It later appeared that BIH was the already specified tool for that.

RD

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 14 Sep 2012 14:34:58 +0200

Hi Lorenzo,

On 11 September 2012 06:29, Lorenzo Colitti <[email-masked]> wrote:

> On Mon, Sep 10, 2012 at 10:38 PM, Wojciech Dec <[email-masked]>wrote:
>

In my opinion this setup does require something not obvious to developers
and that it risks "polluting" the notion of an iPv6 link and subnet (ie
developers getting it wrong, and then further architectures be built on
this). The device in the middle (eg CLAT) would have its upstream (p2p) and
downstream (broadcast) interfaces all effectively on the same /64 and I'm
assuming "on-link". This then becomes either a case of some translational
bridging in action (the p2p upstream has a different link layer than the
bcast downstream), or a proxy-something (eg ND), virtual interfaces, etc.
This can indeed be made to work and be robust, but it doesn't change the
fact that this setup is not exactly simple, and it is not how one would
these days link up two different media-types along with IP routing.

Agreed.

-Woj.