Subject: Re: [v6ops] A way forward for 464XLAT

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

Hi, Cameron,

Sorry for the late answer (was on second priority for a few days).

Le 2012-03-27 à 12:38, Cameron Byrne a écrit :

> hi,
> 
> On Tue, Mar 27, 2012 at 1:17 AM, Rémi Després <[email-masked]> wrote:
>> 
>> Le 2012-03-27 à 04:34, Fred Baker a écrit :
...
>>> 
>>> The objections raised in the working group come down to:
>>>   - the authors of said other documents would like to have a conversation with the 464XLAT folks
>>>   - What's this about a prefix::/96?
>>>   - What's this about a proxy service?
>> 
>> There was also a point about NAT44 in CLAT nodes or not (point discussed on the ML)
>> 
> 
> The NAT44 text on the CLAT has been integrated here:
> 
> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.5
> 
> "Alternatively, the CLAT may do NAT44
>   such that all private IPv4 sourced LAN packets appears from one
>   private IPv4 address which is statelessly translated to one IPv6
>   address that the CLAT will own as a host IPv6 address from an IPv6
>   /64 interface."

Thanks, good enough for me.

>> May I add that the relationship between 464XLAT and BIH (RFC6535) would also be worth clarifying. (I see high similarity: v4 only applications communicating in IPv6).
>> 
> 
> BIH explicitly does not allow double translation, it's scope is
> explicitly limited to the case of using IPv4 applications to IPv6-only
> servers.  I objected to this limitation in BEHAVE.  But, it is what it
> is.

BIH "recommends" to avoid double translation.
This AFAIK permits it if good reasons are found.

> That said, 464XLAT authors have found rfc6145 to be the best fit for
> IPv4->IPv6 translation, including support for the function in a more
> generic node such as a router (home gateway CPE, mobile phone as a
> host, mobile phone as a wifi router, ...)

BIH does include RFC6145 translation.

> where BIH is constrained to
> a host only style implementation that relies on host level API
> modification and interaction

A host can also be also a router, in particular if it includes a NAT44.
I see nothing that prevents using it in this case.

>>>   - What's this about normative language?
>> 
>>>   - How does it fit the the mdt-softwire-map specifications, which
>>>     appear to have a growing consensus behind them in softwire?
>> 
>> The point made during the meeting was about the work in Softwire in general. replacing this point by a reference to the mdt draft is a biased interpretation.
>> In Softwire, a choice between MAP and Unified is scheduled for Friday morning. As chair of v6ops, it would be better to avoid making a Softwire choice before the scheduled debate has taken place (IMHO).
>> Thanks.
>> 
> 
> I hope my previous emails have made the case for a stateful solution
> clear and useful

I thought we had both understood that there are needs for stateful AND ALSO for stateless, in particular where mesh topologies are desirable. This depends on provider cases.
End of this issue for me.  

> As it stands, there is no workable stateful (more IPv4 address
> efficient / intensive) IETF method of operating in an IPv6-only access
> network.  

> NAT64/DNS64 is not workable, since 15% of applications on
> mobile (something similar for desktop) fail to work without some way
> to deal with IPv4 specific sockets and IPv4 literals.

Can we agree to only say that NAT64/DNS64 is NOT SUFFICIENT? (Without saying that it doesn't do work for what it has been designed for). 

Regards,
RD

> 
> CB
>> regards,
>> RD
>> 
>> 
>>> 
>>> Before you continue reading this note, please stop and read these two sections:
>>>   http://tools.ietf.org/html/rfc2026#section-4.2.2
>>>   http://tools.ietf.org/html/rfc2026#section-5
>>> 
>>> From my perspective, and from reading those definitions, an Informational Document is a white paper, while a BCP is something that a significant and relevant part of the Internet COmmunity agrees to, and
>>> 
>>> ...since the Internet itself is composed of networks operated by a great
>>>  variety of organizations, with diverse goals and rules, good user
>>>  service requires that the operators and administrators of the
>>>  Internet follow some common guidelines for policies and operations.
>>> 
>>> In other words, operational service models, while not strictly speaking "protocols", can be described in a BCP *standard* as "how to implement a certain service". This is in no sense "the best" or "only way to deploy RFCs 6145/6146", but it might be "the best way to deploy the CLAT service". v6ops is authorized, by charter, to write informational and BCP documents.
>>> 
>>> And since a BCP describes the set of things that one MUST or SHOULD do in deploying such a service, RFC 2119 language regarding that specific service may be acceptable in a BCP describing that service.
>>> 
>>> 
>>> With that preparatory reasoning, it seems to me that we need to separate the contentious parts of the specification so that uncontentious parts can go forward, and other parts can be discussed - whether in this working group or another one.
>>> 
>>> 
>>> Given the points of contention, it seems that the separation needs to be among three documents.
>>> 
>>> The first is a specification - a BCP - for the CLAT service. It refers to RFCs 6052/6144/6145/6146/6147, and describes how translation is used in this context using normative language. It does not refer to a prefix::/96; it refers to RFC 6052. My understanding is that several people have said that this specification is interesting and useful.
>>> 
>>> The second is a separate specification for the proxy service, which is contentious. Being separated, it can be discussed and beaten to death as needed. The first specification says that the CLAT service MAY implement this proxy service. I'm not sure whether that is BCP or Informational; we can discuss that in the context of the rest of the discussion of the proxy service.
>>> 
>>> The third is a report on the trial deployment of the CLAT service by the various companies in question. This is an informational document.
>>> 
>>> Am I making sense? Would this be an acceptable way forward?
>> 
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 3 Apr 2012 07:15:10 -0700

On Apr 3, 2012 12:32 AM, "Rémi Després" <[email-masked]> wrote:
> >> May I add that the relationship between 464XLAT and BIH (RFC6535)
would also be worth clarifying. (I see high similarity: v4 only
applications communicating in IPv6).
> This AFAIK permits it if good reasons are found.

Yes, it is an all capital letter recommendation.  As you likely well know,
ipv6 transition is an ecosystem transition and recommendations like the one
in BIH become a lightening rod for confusion. We can leave it at that.

> BIH does include RFC6145 translation.

If I read section 2.3 correctly of bih, it requires all sessions be created
by enr.

In the network implementation of bih, bih cannot support ipv4 communication
that does not start with DNS because DNS triggers the enr. So, bih on a
router cannot facilitate for a client of  the router a Skype call  since
Skype signals ipv4 literals.
The bih router (which does not exist) cannot create the enr triggered
session mappings with capturing DNS first.

> I see nothing that prevents using it in this case.

I don't believe bih had this use case in scope. The diagrams and text in
bih make reference to a host, not a host / router.

Trust me, if bih worked as you suggest, my life would be much easier. If
bih officially worked with nat64 and did not require the enr mapper so that
it supported ipv4 literals in network mode, that would be great. In fact, I
pushed for both when bih was a draft in behave.

> >> The point made during the meeting was about the work in Softwire in
general. replacing this point by a reference to the mdt draft is a biased
interpretation.
> >> In Softwire, a choice between MAP and Unified is scheduled for Friday
morning. As chair of v6ops, it would be better to avoid making a Softwire
choice before the scheduled debate has taken place (IMHO).
> I thought we had both understood that there are needs for stateful AND
ALSO for stateless, in particular where mesh topologies are desirable. This
depends on provider cases.
> End of this issue for me.

We do agree.

> Can we agree to only say that NAT64/DNS64 is NOT SUFFICIENT? (Without
saying that it doesn't do work for what it has been designed for).

We agree on this too.

Cb
> >>> From my perspective, and from reading those definitions, an
Informational Document is a white paper, while a BCP is something that a
significant and relevant part of the Internet COmmunity agrees to, and
> >>> In other words, operational service models, while not strictly
speaking "protocols", can be described in a BCP *standard* as "how to
implement a certain service". This is in no sense "the best" or "only way
to deploy RFCs 6145/6146", but it might be "the best way to deploy the CLAT
service". v6ops is authorized, by charter, to write informational and BCP
documents.
> >>>
> >>> And since a BCP describes the set of things that one MUST or SHOULD
do in deploying such a service, RFC 2119 language regarding that specific
service may be acceptable in a BCP describing that service.
> >>>
> >>>
> >>> With that preparatory reasoning, it seems to me that we need to
separate the contentious parts of the specification so that uncontentious
parts can go forward, and other parts can be discussed - whether in this
working group or another one.
> >>> The first is a specification - a BCP - for the CLAT service. It
refers to RFCs 6052/6144/6145/6146/6147, and describes how translation is
used in this context using normative language. It does not refer to a
prefix::/96; it refers to RFC 6052. My understanding is that several people
have said that this specification is interesting and useful.
> >>>
> >>> The second is a separate specification for the proxy service, which
is contentious. Being separated, it can be discussed and beaten to death as
needed. The first specification says that the CLAT service MAY implement
this proxy service. I'm not sure whether that is BCP or Informational; we
can discuss that in the context of the rest of the discussion of the proxy
service.
> >>>
> >>> The third is a report on the trial deployment of the CLAT service by
the various companies in question. This is an informational document.

---

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

...
> Yes, it is an all capital letter recommendation. 
> 
- RFC 6535 says "Use of BIH together with a NAT64 is NOT RECOMMENDED".
- RFC 2119 says that "NOT RECOMMENDED" means that "there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful".
- 464XLAT-like scenarios are IMHO "valid reasons in particular circumstances" that justify using "BIH together with a NAT44" 

> As you likely well know, ipv6 transition is an ecosystem transition and recommendations like the one in BIH become a lightening rod for confusion.
> 
Having not followed the Behave debate on BIH, I just read the resulting RFC with an open mind.
So far, I don't know anything that justifies this negative appreciation. 

> We can leave it at that.
IMHO, BIH is not only valuable for its documented v4-only-to-v6-only use cases, but also for use cases targeted by 464XLAT.  
For such scenarios, it looks sufficient that:
(a) RFC 6535 is used in its socket-layer variant (ignoring the network layer variant, as already recommended in sec. 4)
(b) In hosts whose only interface is IPv6, all IPv4 packets are subject to protocol translation (as already implicitly suggested in sec 4.5)
(c) IPv6 addresses that, for (b), need to be used as substitute of public IPv4 addresses are synthesized according to RFC 6052 (the available RFC for this).

Thus, a BIH host works in face of an ordinary NAT64 with the same e2e effect as that of a CLAT in face of a PLAT.

Anything missed?

> > > host, mobile phone as a wifi router, ...)
(*) A BIH host that includes a NAT44 can be an IPv4 router on its LAN side, without needing any new specification for this.

...
> If I read section 2.3 correctly of bih, it requires all sessions be created by enr.
> 
(**)
- Section 2.3 of RFC 6535 says "if a DNS A record reply contains non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 addresses". ENR doesn't apply to public IPv4 addresses.
- With RFC 6052 used for 1:1 mappings between public IPv4 address and an IPv6 addresses, sessions are possible with IPv4 referrals (neither DNS nor ENR needed). 

> In the network implementation of bih, bih cannot support ipv4 communication that does not start with DNS because DNS triggers the enr. So, bih on a router cannot facilitate for a client of  the router a Skype call  since Skype signals ipv4 literals. 
> The bih router (which does not exist) cannot create the enr triggered session mappings with capturing DNS first.
> 
No problem with the socket-layer variant (see (a) above) 

> I don't believe bih had this use case in scope. The diagrams and text in bih make reference to a host, not a host / router.
> 
Discussed in (*) above

> Trust me, if bih worked as you suggest, my life would be much easier.
> 
Unless I miss something, this can still be the case :-).
> If bih officially worked with nat64 and did not require the enr mapper so that it supported ipv4 literals in network mode, that would be great.
> 
Discussed in (**) above.

> In fact, I pushed for both when bih was a draft in behave. 
Maybe time has come to acknowledge that what was a "NOT RECOMMENDED" (not a "MUST NOT") is in fact useful for
the following use case:

 (IPv4-only appli or NAT44)
 (BIH with RFC6146)
    v
 IPv6-only network
    v
 (stateful NAT64)
    v
  IPv4 Internet
    v
 (IPv4 server)

Regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Apr 2012 17:22:15 +0900

On Mon, Apr 16, 2012 at 17:09, Rémi Després <[email-masked]>wrote:

> IMHO, BIH is not only valuable for its documented v4-only-to-v6-only use
> cases, but also for use cases targeted by 464XLAT.
> (a) RFC 6535 is used in its socket-layer variant (ignoring the network
> layer variant, as already recommended in sec. 4)
> (b) In hosts whose only interface is IPv6, all IPv4 packets are subject
> to protocol translation (as already implicitly suggested in sec 4.5)
> (c) IPv6 addresses that, for (b), need to be used as substitute of public
> IPv4 addresses are synthesized according to RFC 6052 (the available RFC for
> this).
>
> Thus, a BIH host works in face of an ordinary NAT64 with the same e2e
> effect as that of a CLAT in face of a PLAT.
>

Are you saying that 464xlat can be seen as a particular configuration of
BIH (RFC 6535) in addition of as a particular configuration of RFC 6145 and
RFC 6146?

If so, then that's fine. Since the 464xlat draft defines no new behaviour
but only how to combine existing technologies to achieve a particular
result, the draft can simply say something along the lines of:

  It may be noted that this could also be seen as a particular
  configuration of [RFC 6535] used in its socket-layer variant
  as well as a particular configuration of [RFC 6145] and
  [RFC 6146].

The 464xlat draft should still exist though (perhaps as a BCP as per Fred's
suggestion), to describe the actual scenario, how to configure it, and so
on.

---

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

Le 2012-04-16 à 10:22, Lorenzo Colitti a écrit :

> On Mon, Apr 16, 2012 at 17:09, Rémi Després <[email-masked]> wrote:
> Are you saying that 464xlat can be seen as a particular configuration of BIH (RFC 6535) in addition of as a particular configuration of RFC 6145 and RFC 6146?

The point is that RFC 6535 and RFC6052 are sufficient.

The only (very minor problem) is that RFC 6535 doesn't recommend what should better be recommended for operators that want:
- IPv6-only network operation
- Support of IPv4-only applications
- Possible use of "deep packet inspection solutions like 3GPP standardized Policy and Charging Control (PCC)"

> If so, then that's fine. Since the 464xlat draft defines no new behaviour but only how to combine existing technologies to achieve a particular result, the draft can simply say something along the lines of:
> 
> The 464xlat draft should still exist though (perhaps as a BCP as per Fred's suggestion), to describe the actual scenario, how to configure it, and so on.

The best approach IMHO would be a BCP just explaining that BIH, used with RFC6052 for v4-v6 address translation, is now recommended for IPv4-only-application support via networks supporting stateful NAT64s (without developing other ways to get a similar result).

Whether such a use case should have its own name, such as 464XLAT, is an open question AFAIAC but, provided the BCP is as simple as it can be, I personally don't care.

RD

---

From: Hui Deng <[email-masked]>
Date: Mon, 16 Apr 2012 17:07:31 +0800

I don't know where this discussion comes from, but just clarify one thing,
For socket based translation, it match with the host only
For header translation, it is not necessraily always host, could be others.

Does anybody know where is the definition of the host?

-Hui

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

> - RFC 2119 says that "NOT RECOMMENDED" means that "there may exist valid
> reasons in particular circumstances when the particular behavior is
> acceptable or even useful".
> - 464XLAT-like scenarios are IMHO "valid reasons in particular
> circumstances" that justify using "BIH together with a NAT44"
>
>  As you likely well know, ipv6 transition is an ecosystem transition and
> recommendations like the one in BIH become a lightening rod for confusion.
>
> (*) A BIH host that includes a NAT44 can be an IPv4 router on its LAN
> side, without needing any new specification for this.
>
> ...
>
> - Section 2.3 of RFC 6535 says "if a DNS A record reply contains
> non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4
> addresses". ENR doesn't apply to public IPv4 addresses.
> - With RFC 6052 used for 1:1 mappings between public IPv4 address and an
> IPv6 addresses, sessions are possible with IPv4 referrals (neither DNS nor
> ENR needed).
>
>  In the network implementation of bih, bih cannot support ipv4
> communication that does not start with DNS because DNS triggers the enr.
> So, bih on a router cannot facilitate for a client of  the router a Skype
> call  since Skype signals ipv4 literals.
> If bih officially worked with nat64 and did not require the enr mapper so
> that it supported ipv4 literals in network mode, that would be great.
>
> Discussed in (**) above.
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 16 Apr 2012 11:20:46 +0200

> For header translation, it is not necessraily always host, could be others.

If the host IPv4-only application which uses the IPv4 API happens to be a NAT44, is there anything that would prevent this host from also including an IPv4 router (with a private IPv4 address space)? 

> Does anybody know where is the definition of the host?

In my understanding, a host is the node that is reached at a destination address. 
(If a received packet is forwarded after modification, it must have a new destination address.)

Regards,
RD

---

From: Hui Deng <[email-masked]>
Date: Mon, 16 Apr 2012 17:22:37 +0800

> If the host IPv4-only application which uses the IPv4 API happens to be a
> NAT44, is there anything that would prevent this host from also including
> an IPv4 router (with a private IPv4 address space)?
>
No, it can do both simutanesouly.

-Hui

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Apr 2012 18:33:08 +0900

On Mon, Apr 16, 2012 at 17:57, Rémi Després <[email-masked]>wrote:

> The best approach IMHO would be a BCP just explaining that BIH, used with
> RFC6052 for v4-v6 address translation, is now recommended
> for IPv4-only-application support via networks supporting stateful NAT64s
> (without developing other ways to get a similar result).
>
> Whether such a use case should have its own name, such as 464XLAT, is an
> open question AFAIAC but, provided the BCP is as simple as it can be, I
> personally don't care.
>

But it wouldn't necessarily be an application scenario of BIH. It could
just as well be an application scenario for RFC 6145 and RFC 6146, right?

In either case there needs to be a BCP.

---

From: Rémi Després <[email-masked]>
Date: Mon, 16 Apr 2012 11:33:45 +0200

> No, it can do both simutanesouly.

Same understanding on this, then.
Thanks

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 16 Apr 2012 11:51:05 +0200

Le 2012-04-16 à 11:33, Lorenzo Colitti a écrit :

> On Mon, Apr 16, 2012 at 17:57, Rémi Després <[email-masked]> wrote:
> But it wouldn't necessarily be an application scenario of BIH. It could just as well be an application scenario for RFC 6145 and RFC 6146, right?

The BIH-NAT64 scenario uses only a subset of BIH functions, right.
But:
- Other BIH functions are useful (IPv4-only applications using IPv6-only servers)
- BIH specifies which local IPv4 addresses are seen by applications without interfering with the host IPv6 address format. 

For a short term validation of the RFC6535-RFC6052 combination, I personally ignore whether there is open-source BIH code, and whether some devices could be used for a test. 
Copies of this mail to RFC6535 are added to know more.

> In either case there needs to be a BCP.

Same view,

RD

---

From: Hui Deng <[email-masked]>
Date: Mon, 16 Apr 2012 18:10:48 +0800

may I continue to clarify more,

why socket layer variation is needed, even for header translation, if you
can get a real Ipv4 address, ENR is not needed, skype will go through.

-Hui

>>  The best approach IMHO would be a BCP just explaining that BIH, used
>> with RFC6052 for v4-v6 address translation, is now recommended
> - BIH specifies which local IPv4 addresses are seen by applications
> without interfering with the host IPv6 address format.
>
> For a short term validation of the RFC6535-RFC6052 combination, I
> personally ignore whether there is open-source BIH code, and whether some
> devices could be used for a test.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 16 Apr 2012 06:52:04 -0700

>>>
>>> Whether such a use case should have its own name, such as 464XLAT, is
an open question AFAIAC but, provided the BCP is as simple as it can be, I
personally don't care.
>> In either case there needs to be a BCP.

I may be missing something but socket level usually means using sockets and
local network stack API.

NAT functions like RFC 6145 do not operate like BIH. Right? Local host
sockets are not used. Perhaps bih fits a proxy model, not a Nat model.

464xlat operates as defined in RFC 6145, not BIH.

Is there a problem with how 464xlat is defined?  I see no compelling reason
to add bih, as the 464xlat definition is complete with 6145.

Cb

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 16 Apr 2012 16:00:26 +0200

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

> I may be missing something but socket level usually means using sockets
> and local network stack API.
>
> Is there a problem with how 464xlat is defined?  I see no compelling
> reason to add bih, as the 464xlat definition is complete with 6145.
>

+1 The working of BIH to support a tethered host, ie BIH at the network
layer, appears to be substantially different than with plain 6145/464xlat.

-Woj.

---

From: Hui Deng <[email-masked]>
Date: Mon, 16 Apr 2012 22:47:14 +0800

Cameron,

You could say BIH socket fit proxy model, but BIH header translation does
NAT model.

I can see Remi's point that once BIH get a real IPv4 address, it could work
with RFC 6052,
It does the same as 464xlat.

Best,

-Hui

2012/4/16 Cameron Byrne <[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Apr 2012 23:55:40 +0900

On Mon, Apr 16, 2012 at 23:47, Hui Deng <[email-masked]> wrote:

> I can see Remi's point that once BIH get a real IPv4 address, it could
> work with RFC 6052,

What does "get a real IPv4 address" mean? Apologies if this is already
clear to everyone else.

---

From: Rémi Després <[email-masked]>
Date: Mon, 16 Apr 2012 17:06:46 +0200

Le 2012-04-16 à 16:55, Lorenzo Colitti a écrit :

> I can see Remi's point that once BIH get a real IPv4 address, it could work with RFC 6052,
> What does "get a real IPv4 address" mean?

Sec 2.3 of RFC6535 says:
"if a DNS A record reply contains non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 addresses."
In this case, the remote host IPv6 address has to be obtained according to 6052 (like in RFC6145)

The other case is where the remote-host IPv4 address used by an IPv4 application is a referral.

Hope it clarifies.

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 16 Apr 2012 17:43:25 +0200

2012-04-16 15:52, Cameron Byrne:
...
> NAT functions like RFC 6145 do not operate like BIH. Right? Local host sockets are not used. Perhaps bih fits a proxy model, not a Nat model.
> 
BIH, because it operates between IPv4 and IPv6 APIs doesn't need to do a field-per-field mapping between IPv4 and IPv6 like that of RFC6145. 
But the result is also that what applications see as IPv4 transmissions are IPv6 packets on the wire. 

> Is there a problem with how 464xlat is defined? 
> 

As already said, 464XLAT identifies an important scenario, not documented before, but proposes for it a solution that is less complete and less based on existing RFCs than a BIH-based solution.

A remaining question is whether the open-source BIH implementation, which Hui Deng has just kindly referenced, can be used as is for a test with your unchanged PLAT, or whether some adaptation is needed.

Hopefully someone can make progress on that. 

>  I see no compelling reason to add bih, as the 464xlat definition is complete with 6145.
> 
Proposing several solutions for the same scenario should be avoided.
The idea is rather to have a BCP that simply adds the 464XLAT scenario to the scope of BIH (in addition to its current IPv4-only-application-to-IPv6-only server scenario which is needed anyway).
BIH, with RFC6052 used where applicable, can thus be THE recommended solution for the 464XLAT scenario.

RD

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 16 Apr 2012 09:33:03 -0700

On Mon, Apr 16, 2012 at 8:43 AM, Rémi Després <[email-masked]> wrote:
> BIH, because it operates between IPv4 and IPv6 APIs doesn't need to do a
> field-per-field mapping between IPv4 and IPv6 like that of RFC6145.
> As already said, 464XLAT identifies an important scenario, not documented
> before, but proposes for it a solution that is less complete and less based
> on existing RFCs than a BIH-based solution.
>

Less complete and less based on existing standars, based on what
facts?  And what does this mean for v6ops?

If you have specific feedback about 464XLAT, please propose it.

I have already explained to you that BIH does to fit a NAT model, as
it cannot function in a router (BIH in a router) and faciliate a Skype
call.

The basic scenario BIH fails to meet is this:

1.  CLAT is in a router (Home gateway or mobile phone acting as wifi hotspot)

2.  IPv4-only windows XP host computer running Skype attached to CLAT
router via WiFi

3.   BIH has 1 modes of operation, neither work for this

A.  Network mode

http://tools.ietf.org/html/rfc6535#section-2.4

"When BIH is implemented at the network layer, the IPv4 packets are
   intercepted and converted to IPv6 using the IP conversion mechanism
   defined in the Stateless IP/ICMP Translation Algorithm (SIIT)
   [RFC6145].  The protocol translation has the same benefits and
   drawbacks as SIIT."

ACK --- BIH does RFC 6145.

BUT! It has the following limitation on how how sessions may be
initiated from the attached IPv4-only Windows XP host

http://tools.ietf.org/html/rfc6535#section-2.3

"The network-layer implementation alternative will only be able to
   catch applications' name resolution requests that result in actual
   DNS queries; hence, it is more limited when compared to the socket
   API-layer implementation alternative.  Hence, the socket API-layer
   alternative is RECOMMENDED."

Thus, BIH in network mode CANNOT facilitate IPv4 literals for this scenario

B.  Socket API mode.

BIH may be able to PROXY connections in the API mode, but this
requires some sort of special networking scenario to enable proxying
for all ports, not basic default routing, where the client
communication must pass all the way up the CLAT stack and trigger the
some APIs .... i have never seen this work for something like Skype.
It may work, but i have never seen it done.  And without anyone
publishing these results, i must assume it does not exist.

Even then, i see no benefit over 6145 as defined in 464XLAT today.
We do have published results that using a proxy solution is less
optimal than a NAT model

http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf

> A remaining question is whether the open-source BIH implementation,
> which Hui Deng has just kindly referenced, can be used as is for a test with
> your unchanged PLAT, or whether some adaptation is needed.
>

That sounds like an orthogonal activity to 464XLAT

> Proposing several solutions for the same scenario should be avoided.

Yes.  We have a solution that works and published experimental data.
We provided before 464XLAT application behavior (skype and others
fail) and post 464XLAT behavior (skype and others work).  It is a
known and operational solution.

> The idea is rather to have a BCP that simply adds the 464XLAT scenario to
> the scope of BIH (in addition to its current
> IPv4-only-application-to-IPv6-only server scenario which is needed anyway).

That is not possible since there is no published operational
experience with BIH and BIH technically fails to make certain
scenarios (IPv4 literals, Skype) work in a router for an IPv4 only
attached host.

I am not sure why you would want to push BIH when 6145 is a known
working scenario.  BIH, IMHO, is just 6145 with some unfortunate
feature (ENR) and specification (do not use for for double
translation) limitations.

Can you explain to an v6ops audience why BIH is superior in an
operational context? Using real scenarios that network operators would
have.... so far, all i have seen is that you believe it more
"complete" and more "based on existing standards".  Those statements
do not mean anything specific to me.

CB

---

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

Le 2012-04-16 à 18:33, Cameron Byrne a écrit :

> facts?  

(*) Here is my understanding: 
- The RFC6145-based approach for the 464XLAT scenario is less complete than BIH in that its IPv4-only applications cannot reach IPv6-only servers.
- It is less based on existing standards (meaning "standard-track RFCs") in that it introduces a new format of IPv6 addresses for CLAT nodes. BIH uses doesn't need that (any native IPv6 address that the BIH node uses is sufficient).

> And what does this mean for v6ops?

A BCP for the 464XLAT use case seems to be appropriate in v6ops, be it BIH based or not.

> If you have specific feedback about 464XLAT, please propose it.

That's what I try to do, by clarifying that:
- there is the 464XLAT use case, which I support
- there is a BIH-based way to support it which, being AFAIK more complete and more based on existing RFCs, is IMHO preferable.

> I have already explained to you that BIH does to fit a NAT model,

What you mean by this is unclear to me.

> as

As said, with a NAT44 as BIH IPv4 only application, the node can be an IPv4 router on its LAN side.
Can you explain why, in your understanding, this doesn't work?

> 2.  IPv4-only windows XP host computer running Skype attached to CLAT

Can you explain why this doesn't work with NAT44/BIH, while it works with your proposed RFC6145-based solution?

> Thus, BIH in network mode CANNOT facilitate IPv4 literals for this scenario

Not the proposed mode.

> publishing these results, i must assume it does not exist.

That's where making tests could help.

In the mean time, if you have an explanation why you believe Skype shouldn't work, that would be useful.
(I don't pretend to know Skype in any detail, but I know there are already NAT cascades in the field and have not heard so far that they break Skype.)

> http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf

Thanks, will look at it.

> That sounds like an orthogonal activity to 464XLAT

Not to the 464XLAT use case.

> scenarios (IPv4 literals, Skype) work in a router for an IPv4 only

Proof of these assertions would certainly clarify the debate.

> translation) limitations.

This is AFAIK a much too restrictive understanding of RFC6535.

> do not mean anything specific to me.

That's the point to be clarified.

RD

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 16 Apr 2012 11:37:30 -0700

> - The RFC6145-based approach for the 464XLAT scenario is less complete than BIH in that its IPv4-only applications cannot reach IPv6-only servers.

I still do not know what less complete means.

My understanding is that BIH is less complete since there is no
working model of how it can fit into 464XLAT.

Network mode BIH is theoretically not possible

API mode BIH is theoretically possible (maybe), but i do not believe a
common NAT44 function would trigger the relevant APIs that BIH uses.

> - It is less based on existing standards (meaning "standard-track RFCs") in that it introduces a new format of IPv6 addresses for CLAT nodes. BIH uses doesn't need that (any native IPv6 address tha…

The 02 version will be published soon and will include Ole's
suggestion of 2 modes, including NAT44 on the CLAT. There will be no
new IPv6 address format or ND/DAD activity.

> Can you explain why, in your understanding, this doesn't work?

So your case is that NAT44 is the IPv4 application that BIH API can work with.

My largely uniformed understanding of NAT44 is that the BIH API calls
listed are not involved in common NAT44

http://tools.ietf.org/html/rfc6535#appendix-A

I know this list is not exhaustive, but my understanding is that BIH
did not have NAT44 as a use case in mind.

> Can you explain why this doesn't work with NAT44/BIH, while it works with your proposed RFC6145-based solution?

I am now just understanding what you have in mind is NAT44 -> BIH API
mode -> NAT64

As, where 464XLAT-02 will define NAT44 -> 6145 -> NAT64

The most important difference is that the RFC 6145 exists and i have
tested it extensively (use it every day), while i am unaware of any
implementation of the "NAT44 -> BIH" method.

IMHO, the ENR and API interactions are less general and more
complicated than RFC 6145.

I have brought several cases of 464XLAT working today with open source
commercial solutions

https://sites.google.com/site/tmoipv6/464xlat

Reaching IPv6-only servers from a IPv4-only host is not a case that i,
as a network operator, value very high.

> (I don't pretend to know Skype in any detail, but I know there are already NAT cascades in the field and have not heard so far that they break Skype.)

My understanding has now shifted based on your clarification that BIH
could work, if BIH could support NAT44.

I do not have the expertise about how NAT44 is implemented to tell if
BIH could support NAT44 definitively.

Either way, AFAIK, NAT44 -> BIH does not exist today and there is no
published experiences of it working.

I don't want to be in a situation where i have to prove BIH does not
work to justify that RFC 6145 is the right path, especially since i
don't believe BIH has any practical or theoretical advantages over RFC
6145.

CB

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Apr 2012 10:48:35 +0900

> IPv4-only-application-to-IPv6-only server scenario which is needed anyway).

I disagree that getting IPv4-only applications to communicate with
IPv6-only servers is an important goal that we should pursue now.

Servers will need to stay IPv4-capable for many years anyway, in order to
continue to support IPv4-only client OSes and networks. So we'd be solving
a problem that doesn't actually exist today.

>From an implementation perspective, I also really don't like the idea of
messing with the socket stack to make this use case work. It's much more
complicated than 464xlat, which just translates packets on the wire.

So if your statement is "this draft should be presented as a use case for
BIH instead of as a use case for RFC 6145, because we need another thing
that BIH can do for us anyway", then I disagree.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Apr 2012 08:11:41 +0100

On 2012-04-17 02:48, Lorenzo Colitti wrote:
...
> a problem that doesn't actually exist today.

I agree strongly. No rational economic actor will attempt to provide an
IPv6-only application service for many years. There really isn't a shortage
of IPv4 addresses for content provision or other application services, and
there are a few billion IPv4 customers out there.

To be clear, this does not rule out running IPv6-only servers fronted
by some form of NAT46; some operators might conclude that this would
reduce OPEX. But the service offered to the Internet would then appear
to be dual stacked.

This seems to be completely orthogonal to the 464XLAT use case.

   Brian

---

From: Rémi Després <[email-masked]>
Date: Tue, 17 Apr 2012 10:51:58 +0200

Lorenzo, Brian, Cameron,

Let me explain more.

1. The 464XLAT use case is:

(IPv4-only client)
       LAN                
  (CLAT router)   OR  (IPv4 appli in CLAT host)      
                  ||
                  \/
        *IPv6-only network*
             (NAT64)
          IPv4 Internet
          (IPv4 server)

2. With BIH in the CLAT CPE, a complementary use case is also available:

 (IPv4-only client)
        LAN                
   (CLAT router)     
        ||
        \/
*IPv6-only network*
   IPv6-Internet
*IPv6-only network 2*
(IPv6-capable server)
 
Thus, although Network 2 is IPv6 only, its servers remain reachable by some IPv4-only clients.
This contributes to facilitate commercial deployments of IPv6-only networks, an objective of IETF AFAIK.

3. Conclusion:
- RFC6535 does exist on standard track
- 464XLAT purpose is to facilitate deployments and use of IPv6-only networks.
- It does this better if combined there is BIH in CLAT nodes.

Having not been involved in BIH specification, I feel free to ask for "no NIH for BIH".

4. Sorry for having mixed in a previous email what applies to router-supporting hosts with what only applies to router-less hosts. Contrary to what I wrote,  the BIH variant that must be used in router-supporting hosts (and may be used in router-less hosts) is the network-layer variant. 

The node architecture is then:
+---------------------------------+
|                                 |
|   IPv4 stack       IPv6 stack   |
|       |                  |      |
| +------------+           |      |
| |    NAT44   |           |      |
| +------------+           |      |
|       |                  |      |
|     +-----------------------+   |
|     |           BIH         |   |
|     +-----------------------+   |
|                 |               |
|         IPv6 WAN interface      |
+---------------------------------+

5. I will carefully read the newly posted 464XLAT draft, and comment next.
In the mean time, comments on the above are welcome.

Regards,
RD

---

From: GangChen <[email-masked]>
Date: Tue, 17 Apr 2012 22:08:26 +0800

Hello Cameron,Remi, Lorenzo, Brian,

As an implementer of BIH, please allow me to share some experiences in
464XLAT contexts.

We implemented/tested BIH on both wireless and wireline network in 464 manner.
Two variants had been developed as listed below.

1) OMS(Android based OS) + BIH with DNS64/NAT64

The mobile handset is a U900 phone (produced by ZTE, OMS 2.0) running
the BIH software.
NAT64 prefix is preconfigured on the phone
Stateful NAT64 and DNS64 are located on a network side.
We have tested several applications including Skype, instant message
(MSN/QQ/Fetion), HTTP, VoD, etc
The outcomes indicate all the tested apps could be supported
transparently based on embeded BIH modules
This demonstration had been formally shown at 3GPPSA2#85 meeting.
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_85_XiAN/docs/S2-112437.zip

2) PON CPE+BIH with DNS64/NAT64

We implemented BIH on CPE (i.e. ZXA10 F660)as well.
Two scenarios are considered so far
Scenario 1: IPv4 hosts connect BIH-CPE to access IPv4 server through
IPv6 network
Scenario 2: IPv4 hosts connect BIH-CPE to access IPv6 server located
in IPv6 network
Different applications have been tested, including Skype,MSN,...
All test cases were passed. We don't see any problem.
Please see the report for more information
http://code.google.com/p/bump-in-the-host/downloads/list

Gang

2012/4/17, Rémi Després <[email-masked]>:
> 4. Sorry for having mixed in a previous email what applies to
> router-supporting hosts with what only applies to router-less hosts.
> Contrary to what I wrote,  the BIH variant that must be used in
> router-supporting hosts (and may be used in router-less hosts) is the
> network-layer variant.
>

---

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

> We have tested several applications including Skype,

In this scenario, is it right that it illustrates that BIH can be used by applications that use referrals (and don't use the DNS)?

Thanks.

RD

> instant message

---

From: GangChen <[email-masked]>
Date: Tue, 17 Apr 2012 22:28:20 +0800

2012/4/17, Rémi Després <[email-masked]>:
> In this scenario, is it right that it illustrates that BIH can be used by
> applications that use referrals (and don't use the DNS)?

Positive. because the preconfigured nat64 prefix.

Gang

PS: Is this RFC6535+RFC6052?

>>> Thus, although Network 2 is IPv6 only, its servers remain reachable by
>>> some
>>> IPv4-only clients.
>>> This contributes to facilitate commercial deployments of IPv6-only
>>> networks,
>>> an objective of IETF AFAIK.
>>>
>>> 3. Conclusion:

---

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

> PS: Is this RFC6535+RFC6052?

In my understanding, that's the combination that makes it work.

Actually, since RFC6535, in its network-layer variant, explicitly refers to RFC 6145, which explicitly refers to RFC6052, that's just using BIH as is ;-).

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Apr 2012 15:53:40 +0100

Bonjour Rémi,

On 2012-04-17 09:51, Rémi Després wrote:
...
> This contributes to facilitate commercial deployments of IPv6-only networks, an objective of IETF AFAIK.

Really? As far as I know we have always suggested that dual stack was
the preferred deployment model. Certainly if I was a commercial
application layer provider, I would not consider using an IPv6-only
ISP for one moment, because that would disadvantage my IPv4 customers.

Note, this is not a comment on the technology, but on whether there's
a real operational use case today.

   Brian

---

From: Gert Doering <[email-masked]>
Date: Tue, 17 Apr 2012 16:58:15 +0200

Hi,

>From an operator perspective, serving content, I do not see any benefit
in going to IPv6-only-content any time soon.  Content needs to be 
dual-stacked.

OTOH, I see great value in IPv6-single-stacking eyeballs (plus adding a
client-ISP side NAT64+DNS64 for v4-only content).  Not everybody, not
right away, but "soon".

Gert Doering
        -- Operator
-- 
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: Rémi Després <[email-masked]>
Date: Tue, 17 Apr 2012 17:02:13 +0200

> a real operational use case today.

The point is that all this 464XLAT discussion is in the context of IPv6-only operator networks. 
My understanding is that deployments of IPv6-only networks are seriously envisaged in the context of LTE.

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Apr 2012 16:38:58 +0100

> My understanding is that deployments of IPv6-only networks are seriously envisaged in the context of LTE.

Exactly, but that does not put content providers on an IPv6-only network.
I fully agree with Gert Doering's message.

    Brian

---

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

> Exactly, but that does not put content providers on an IPv6-only network.

I agree that any server, even the smallest one, if intended to be reached by IPv4-only clients should better be dual-stack capable.
This has always been my stand.

But now that some IPv6-only networks are seriously envisaged, and without IPv4 incoming connectivity offered to customer sites, such a dual-stack-capable server can be unable to use its IPv4 stack. 
It can however remain reachable by IPv4-only clients whose CPEs are BIH capable. 
Importance of this plus can be discussed, sure, but its being a plus can AFAIK hardly be denied. 

Since, as we just learned, there is already BIH open-source running code, why would one refuse to even consider it?

In addition, and as I will explain in a response to Masanobu Kawashima, 4X4XLAT has the problem of using multiple IPv6 prefixes in customer sites, a problem that doesn't exist with BIH.

Kind regards,
RD

---

From: Hui Deng <[email-masked]>
Date: Wed, 18 Apr 2012 12:37:51 +0800

Hello all

As I spoke during the last IETF meeting, this scenario is an valid and
deserved to solve it.
I guess people here who are discussing in order to make it a better IETF
document.

I would like to comment below wording based on Dave's writeup during
shepherd.
you can look at the link below:
http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/history/

copy and paste:
 The present document does not, however, mandate (or even recommend)
the RFC 2767-like implementation option.  In fact, for the name
synthesis part, it recommends the other option, and for the data
translation portion, no recommendation is made either way.
You could understand only name synthesis is not commended,
for literal, I don't see that statement valid.

Best

-Hui

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 22 Apr 2012 18:01:04 -0700

> My understanding is that deployments of IPv6-only networks are seriously envisaged in the context of LTE.

ipv6 only pdp contexts exist today, lte or no.

---

From: Rémi Després <[email-masked]>
Date: Mon, 23 Apr 2012 09:58:22 +0200

> ipv6 only pdp contexts exist today, lte or no.

Yes, the right sentence would have been "IPv6-only networks are seriously envisaged in the context of 3GPP"
Thanks,
RD