Subject: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

From: [email-masked]
Date: Fri, 19 Sep 2014 04:47:01 -0700

A new draft has been posted, at http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. Please take a look at it and comment.

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Fri, 19 Sep 2014 18:41:16 +0200

Looks like a reference to http://tools.ietf.org/html/rfc7051#page-15
could be useful, as well as the more detailed discussion of what
factors are preventing from using the RFC7050's method ?

The short sentence "But it is difficult and depends on DNS64" raises
immediate questions:

1) "it is difficult"

Needs to be qualified/reasoned.

C code to create a DNS request can be implemented in ~200 lines, and
the code to parse it can be done in ~300 lines, so even a host that
does not use the DNS otherwise can have a lightweight module just for
the sake of getting a prefix. That host already has to implement
DHCPv6 client, this does not look like a lot of code nor a lot of
complexity in comparison.

2) "requires DNS64"

This in itself could be a valid consideration for a 464XLAT deployment
choose to not use DNS64.

But: what is the best *real-world* operational practice today - to use
DNS64 or not ?

If the real-world practice shows that DNS64 is harmful in 464XLAT
deployments, this should be documented accordingly - and then there
would be no uncertainty about the rationale for this approach.

If the best practice is to use DNS64 anyway, then do we want to steer
people away from it by providing a method that does not depend on
DNS64 ?

--a

On 9/19/14, [email-masked] <[email-masked]> wrote:
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. Please
> take a look at it and comment.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Sep 2014 00:26:15 +0900

> take a look at it and comment.

What's the use case for this draft?

To date, the primary deployment of 464xlat has been in 3GPP (i.e.,
cellular) networks. In general, these networks do not support DHCPv6. In
fact, the fact that 464xlat did not need DHCP was one of the main reasons
that the industry went with 464xlat and not something better like DS-Lite
or MAP. (464xlat is pretty much the worst.)

If you can depend on DHCPv6, there's very little reason to use 464xlat at
all. There are much better transition mechanisms available.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 22 Sep 2014 15:56:07 +0000

On 22 Sep 2014, at 15:26 , Lorenzo Colitti <[email-masked]> wrote:

> To date, the primary deployment of 464xlat has been in 3GPP (i.e., cellular) networks. In general, these networks do not support DHCPv6. In fact, the fact that 464xlat did not need DHCP was one of the main reasons that the industry went with 464xlat and not something better like DS-Lite or MAP. (464xlat is pretty much the worst.)
> 
> If you can depend on DHCPv6, there's very little reason to use 464xlat at all. There are much better transition mechanisms available.

What can I do to my v4-only binary-only socket applications on my IPv6-only kernel unixy machine?  Yes, does exist.
A good xlat464 implementation might save my day. 

— 
Bjoern A. Zeeb             "Come on. Learn, goddamn it.", WarGames, 1983

---

From: Ross Chandler <[email-masked]>
Date: Mon, 22 Sep 2014 17:48:43 +0100

On 22 Sep 2014, at 16:26, Lorenzo Colitti <[email-masked]> wrote:

> , the fact that 464xlat did not need DHCP was one of the main reasons that the industry went with 464xlat and not something better like DS-Lite or MAP. (464xlat is pretty much the worst.)
> 

I think it depends on the version of MAP. I’d group 464xlat with MAP-T and DS-Lite with MAP-E, the former translating headers and the latter encapsulating.
AFAIK DPI for IPv4 in IPv6 traffic is not supported by my GGSN/PGW vendor. 

In 3GPP Mobile 464xlat is a good, proven solution.  DS-Lite goes back to a central AFTR inheriting the limitations of NAT44. 

BR 
Ross

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Sep 2014 01:52:16 +0900

On Tue, Sep 23, 2014 at 12:56 AM, Bjoern A. Zeeb <
[email-masked]> wrote:

> What can I do to my v4-only binary-only socket applications on my
> IPv6-only kernel unixy machine?  Yes, does exist.

But you don't need DHCPv6, you can just use DNS64?

---

From: <[email-masked]>
Date: Tue, 23 Sep 2014 08:18:10 +0200

Hello *,

> take a look at it and comment.

Some comments on this draft:

* The discovery via DNS64 (RFC7050) in the scenarios where 464XLAT is being used works pretty well. What are the scenarios where the RFC7050 mechanisms do not work well, and XLAT prefix discovery needs to be done via DHCPv6?
* NAT64 and 464XLAT are currently mainly used in mobile environments. What would be the "vehicle" to get DHCPv6 based NAT64 prefix distribution into the mobile standards/mobile devices?
* Will the presence of the DHCPv6 PLATPREFIX option in messages from the DHCPv6 server implicitly tell the device that the access network is IPv6-only and no effort has to be made for a native IPv4-only connectivity?
* I believe it would be good to also allow the PLATPREFIX option during stateless DHCPv6 when the IPv6 address itself has been obtained via RA/SLAAC.
* This document only discusses about obtaining the NAT64 prefix for CLAT. However, it is also necessary if the end device has a local DNS64 (to locally prefer native generation of the packets in IPv6 instead of generating them with IPv4 and translating them into IPv6 via CLAT).

Holger

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 23 Sep 2014 08:52:51 +0000

Agree, encapsulation messes with with 3GPP policy and charging, translation is in keeping with 3GPP architecture.
Lorenzo, what do you see as the advantages MAP-T would have over 464xlat?
Regards,
Nick

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Ross Chandler
Sent: 22 September 2014 17:49
To: Lorenzo Colitti
Cc: [email-masked]; [email-masked] WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

> If you can depend on DHCPv6, there's very little reason to use 464xlat at all. There are much better transition mechanisms available.

I think it depends on the version of MAP. I'd group 464xlat with MAP-T and DS-Lite with MAP-E, the former translating headers and the latter encapsulating.
AFAIK DPI for IPv4 in IPv6 traffic is not supported by my GGSN/PGW vendor. 

BR 
Ross

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Sep 2014 21:05:56 +0900

On Tue, Sep 23, 2014 at 5:52 PM, Heatley, Nick <[email-masked]>
wrote:

> Agree, encapsulation messes with with 3GPP policy and charging,
> translation is in keeping with 3GPP architecture.

If you want real IPv4, MAP-T is more transparent, scales better, and does
not require a big stateful NAT in the sky. In wired networks, I'd say it's
better.

For a mobile network where bandwidth is low and margins are high and there
is already a big stateful NAT in the sky, the only real advantage is
transparency. Given the typical state of IPv4 in mobile networks, even that
advantage is moot.

I think 464xlat is a perfect fit for mobile networks. My favourite feature
is that it sounds so bad that developers want to get the hell away from it
and onto native IPv6 as soon as they can :-)

---

From: Sander Steffann <[email-masked]>
Date: Tue, 23 Sep 2014 14:11:50 +0200

> I think 464xlat is a perfect fit for mobile networks. My favourite feature is that it sounds so bad that developers want to get the hell away from it and onto native IPv6 as soon as they can :-)

Best argument in favour of 464xlat that I ever heard! :)
Sander

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Tue, 23 Sep 2014 15:05:39 +0000

I think you can always set static clat config for devices you controlled, or implement CLAT on application level...why not? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2014 8:18 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Hello *,

> http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. Please take a look at it and comment.

Holger

---

From: "Lishan Li" <[email-masked]>
Date: Wed, 24 Sep 2014 19:27:56 +0800 (CST)

Dear Andrew,

Thanks for your comments and the reference pointer. It's of great help.

I agree with your idea. But what I intended to mean was that the message exchange of DNS64 is "complicated" not "difficult".
Learning the IPv6 Prefix using DHCPv6 looks like lower complexity in comparison.

The main purpose of the draft is not steering people away from DNS64. Learning the IPv6 prefix using DHCPv6 is simple
and direct. DHCPv6 is designed to provide various kinds of configuration information in a centrally managed fashion.

Best regards,
Lishan Li

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Sep 2014 20:37:20 +0900

On Wed, Sep 24, 2014 at 8:27 PM, Lishan Li <[email-masked]> wrote:

> I agree with your idea. But what I intended to mean was that the message
> exchange of DNS64 is "complicated" not "difficult".

Ok, but once you've learned the prefix using DHCPv6, what do you do with
it? You still need a DNS64 unless you want to pump all the traffic through
464xlat, which is terrible for performance.

---

From: <[email-masked]>
Date: Wed, 24 Sep 2014 11:47:54 +0000

Dear Lishan,

FWIW, I’m one of the authors of the DHCPv6 option analyzed in RFC7051. We abandoned the dhcpv6 track because the recommendation of the behave wg at that time is the heuristic-based approach.

As you can read in document shepherded for rfc7050, the wg is aware of the limitations of the solution (https://datatracker.ietf.org/doc/rfc7050/history/):

   “The document specifies a heuristic that is not perfect and so some
    points were rough, but the constraint for this document was to operate
    without changes to code (only configuration) in existing networks.
    Given that constraint, there was strong consensus.  Relaxing the
    constraint would allow one to do better, and that is the focus of a
    draft recently submitted to the PCP WG.”

Since then, RFC7225 was published by the pcp wg.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de Lishan Li
Envoyé : mercredi 24 septembre 2014 13:28
À : Andrew 👽 Yourtchenko
Cc : [email-masked]; [email-masked]
Objet : Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Dear Andrew,

Best regards,
Lishan Li

>On 9/19/14, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> wrote:

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

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

---

From: "Lishan Li" <[email-masked]>
Date: Wed, 24 Sep 2014 20:24:20 +0800 (CST)

Dear Lorenzo,

Thanks a lot for your comments and explanation of 464xlat, which does help me to understand it more precisely. 

As for this comment:

>Ok, but once you've learned the prefix using DHCPv6, what do you do with it? You still need a DNS64 unless you want to pump all the traffic through 464xlat, which is terrible for performance.

What do you mean by “all the traffic”? From my reading of RFC6877, all the IPv4 traffic should go through 464xlat but all the v6 traffic should go native v6 (please correct me if I’m wrong, thanks!). Our proposal didn’t intent to change that… 

Thanks!

Lishan Li

在 2014-09-24 19:37:20，"Lorenzo Colitti" <[email-masked]> 写道：

Ok, but once you've learned the prefix using DHCPv6, what do you do with it? You still need a DNS64 unless you want to pump all the traffic through 464xlat, which is terrible for performance.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Sep 2014 21:30:14 +0900

> What do you mean by “all the traffic”? From my reading of RFC6877, all the IPv4 traffic should go through 464xlat but all the v6 traffic should go native v6 (please correct me if I’m wrong, thanks!…

All traffic to an IPv4 server, e.g., to the vast majority of websites and
cloud providers.

- Using 464xlat / NAT64 / DNS64, traffic to an IPv4 server will use native
IPv6 and then NAT64
- Withoug DNS64, traffic to an IPv4 server will IPv4 and then 464xlat and
then NAT64

---

From: "Lishan Li" <[email-masked]>
Date: Wed, 24 Sep 2014 20:34:04 +0800 (CST)

Dear Med and all,

Many thanks for the information! This does a lot of good to my understanding of the whole 464xlat/behave story (and sorry for missing that part). The reason for this draft is that we found the RFC(s) allows a second method for prefix discovery and we thought DHCP might be an option here. 

Now I get the whole picture and will do some research on the related RFCs. 

Thanks again!

Best regards,

Lishan Li

在 2014-09-24 19:47:54，[email-masked] 写道：

Dear Lishan,

Cheers,

Med

De : v6ops [mailto:[email-masked]] De la part de Lishan Li
Envoyé : mercredi 24 septembre 2014 13:28
À : Andrew 👽 Yourtchenko
Cc :[email-masked]; [email-masked]
Objet : Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Dear Andrew,

Best regards,

Lishan Li

---

From: <[email-masked]>
Date: Wed, 24 Sep 2014 14:44:00 +0200

Hello,

all the traffic generated by an IPv4-only application, going to an IPv4 or Dual Stack server, should go through CLAT+PLAT.

But, all the traffic generated by a Dual Stack application, going to an IPv4 server, should not go through CLAT, only PLAT, thus, the application should generate the IPv6 packets targeted at the PLAT for 6->4 translation directly (see the table at the end of section 7.2 of RFC 6877). Since CLAT usually runs on a low(er)-performance end device, its use should be avoide if possible. And, by today, this type of traffic is the vast majority as far as I can judge.

If you don’t have a DNS64 (located either at the provider, or locally), the latter cannot be achieved.

Holger
Von: v6ops [mailto:[email-masked]] Im Auftrag von Lishan Li
Gesendet: Mittwoch, 24. September 2014 14:24
An: Lorenzo Colitti
Cc: [email-masked]; [email-masked] WG
Betreff: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

 Dear Lorenzo,

Thanks!
Lishan Li

在 2014-09-24 19:37:20，"Lorenzo Colitti" <[email-masked]<mailto:[email-masked]>> 写道：

On Wed, Sep 24, 2014 at 8:27 PM, Lishan Li <[email-masked]<mailto:[email-masked]>> wrote:
I agree with your idea. But what I intended to mean was that the message exchange of DNS64 is "complicated" not "difficult".
Learning the IPv6 Prefix using DHCPv6 looks like lower complexity in comparison.

---

From: Tore Anderson <[email-masked]>
Date: Wed, 24 Sep 2014 14:51:26 +0200

* Lorenzo Colitti

> it? You still need a DNS64 unless you want to pump all the traffic
> through 464xlat, which is terrible for performance.

AIUI, Orange Poland has opted to use 464XLAT without DNS64 (see
http://www.data.proidea.org.pl/plnog/12edycja/day2/track4/01_ipv6_implementation.pdf
slides 7 and 8). Presumably they hard code the PLAT prefix in their
handsets to make this work. A DHCPv6 option would allow their handset to
dynamically discover the PLAT prefix instead.

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Sep 2014 22:02:18 +0900

> dynamically discover the PLAT prefix instead.

Orange Poland is a 3GPP network, and 3GPP networks usually do not support
DHCP.

Also, you don't need DHCP for that. All you need to do is have your DNS
server return appropriate answers to AAAA queries for "ipv4only.arpa".

Having spent a fair bit of time on the Android clat daemon, I don't know
why you would want to use it without DNS64. I wasn't able to find a reason
for that (or even a confirmation that this is what they are doing) in the
slides. Do you know what they are doing, and why?

---

From: <[email-masked]>
Date: Wed, 24 Sep 2014 15:38:05 +0200

Hello,

> Having spent a fair bit of time on the Android clat daemon, I don't know why you would want to use it without DNS64. I wasn't able to > find a reason for that (or even a confirmation that this is what they are doing) in the slides. Do you know what they are doing, and why?

I can’t speak for them, but for a mobile provider providing Dual Stack services and IPv6-only services, it is hard to decide at the DNS whether a dual Stack Host is asking (=no DNS64 to be done) or a single IPv6 stack host is asking (=DNS64 needs to be done).

One solution would be to have different client IPv6 address ranges for Dual Stack hosts and IPv6-only hosts. Another thing would be to hand out to the Dual Stack hosts only an IPv4 DNS resolver address, so the DNS resolver knows that all queries that come via IPv6 transport are from IPv6-only hosts. Another solution is to hard code the PLAT prefix into clatd, so your DNS doesn’t need to do the above separation of queries.

Holger

---

From: Tore Anderson <[email-masked]>
Date: Wed, 24 Sep 2014 17:23:26 +0200

* Lorenzo Colitti:

> Orange Poland is a 3GPP network, and 3GPP networks usually do not
> support DHCP.

True, for now at least. It was just an example though, it could just as
easily have been a wireline ISP that puts a CLAT in their CPEs and runs
dual-stack on the LAN segments.

I mentioned Orange Poland specifically because they're an *actual*
example of a network that uses 464XLAT without DNS64. See
http://www.ietf.org/mail-archive/web/v6ops/current/msg19619.html for the
confirmation you asked about below.

> server return appropriate answers to AAAA queries for "ipv4only.arpa".

Good point.

> why you would want to use it without DNS64. I wasn't able to find a
> reason for that (or even a confirmation that this is what they are
> doing) in the slides. Do you know what they are doing, and why?

As to the why, slide 7 says: «CLAT+DNS64 - problems with apps where ipv4
literals&domain names are used».

I can easily think of one example; FTP. If an IPv6-only FTP client is
speaking to an IPv4-only FTP server through a single layer of
translation (NAT64/PLAT), it won't work. The client won't know what to
do with the literal IPv4 addresses the server asks it to connect to for
the data connection. With dual translation (CLAT+PLAT), it will work.
ALGs in the PLAT could help, but not if encryption is being used (e.g.,
FTP/TLS).

In general, dual translation looks more like native IPv4 to the
applications, so it might result in slightly fewer interoperability
problems than single translation.

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 25 Sep 2014 00:32:54 +0900

> dual-stack on the LAN segments.

But in that case, why wouldn't you use MAP? It provides much better IPv4
connectivity, it's stateless, it scales better...

> FTP/TLS)

Not sure I understand what you mean here. Did you mean "the server won't
know what to do with the literal IPv6 address the client asks it to connect
to"?

---

From: Tore Anderson <[email-masked]>
Date: Wed, 24 Sep 2014 19:07:27 +0200

* Lorenzo Colitti

> connectivity, it's stateless, it scales better...

Maybe you already have boxes already capable of NAT64 lying around, and
no room on your budgets for new MAP boxes? I don't know...you could say
the same thing about DS-Lite, but people are deploying that, too. So it
wouldn't surprise me in the least if someone were to put a CLAT in a
CPE, either.

> know what to do with the literal IPv6 address the client asks it to
> connect to"?

Looked a bit more into it, and I think FTP was a poor example. It works
when the client is on IPv6. It's worse if the client is on IPv4 and
accessing an IPv6 server through SIIT; but it works again with if you
use dual translation so the server thinks it's on IPv4 too.

Anyway, I suppose it would be better to ask the Orange Poland guys, they
should know best which specific application problems they ran into with
464XLAT+DNS64 that caused them to forego DNS64.

Tore

---

From: "Heatley, Nick" <[email-masked]>
Date: Thu, 25 Sep 2014 08:32:28 +0000

There appear to be two schools of thought around the NAT64 in the 464xlat:
1. run NAT64 as dumb as possible, don't look to use ALGs, prefer double translations to hide upper layer issues
2. try to achieve parity between NAT64 and NAT44 in terms of ALGs and session helpers supported, then allow single translations over double translations

If you are in the 2nd camp then you will happily allow DNS64, and use CLAT only for literals.
Otherwise you aim to use the CLAT rather than DNS64.

Holger gave a scenario behind camp1 thinking - a mixed environment of dual stack / IPv6-only devices.
However looking deeper, does it further depends if you have public IPv4 or private IPv4 for the dual stack.
If you are in camp 1, absence of DNS64, and you use public IPv4 you may avoid NAT altogether on the IPv4 dual stack path (otherwise synthesised IPv6 destinations will take pref over IPv4).
(=> enough public IPv4 for dual stack cellular devices, lucky you!)
If you accept that your dual stack devices will be using private IPv4 then it really is down to whether the NAT64 path from DNS64 can match NAT44 IMHO. (i.e. has your NAT64 vendor written those ALGs yet...)

BTW here is some background on FTP over 464xlat that Ross and I debated:
https://code.google.com/p/android/issues/detail?id=71835
I am happy with FTP now that we modified the behaviour of our NAT64 firewall (allow PASV over IPv6 transport). 
The other aspect in the mix is the existence of pre-RFC2428 FTP servers (some 50% of internet FTP servers allegedly), which makes FTP quite special and interesting for translation behaviour.

I guess I am in camp 2, I believe my NAT64 is as good as my NAT44 (with the proviso that testing is ongoing...), and you will never solve complex or higher layer issues, like active FTP, without resorting to ALGs.
Until someone shows why NAT64 cannot equal NAT44 in service experience, I am placing my bets on NAT64 ALGs. 
I welcome comments on NAT64 security and upper layer protocol concerns here, happy to test.
BR
Nick

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Tore Anderson
Sent: 24 September 2014 18:07
To: Lorenzo Colitti
Cc: [email-masked]; [email-masked] WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

* Lorenzo Colitti

> But in that case, why wouldn't you use MAP? It provides much better 
> IPv4 connectivity, it's stateless, it scales better...

Maybe you already have boxes already capable of NAT64 lying around, and no room on your budgets for new MAP boxes? I don't know...you could say the same thing about DS-Lite, but people are deploying that, too. So it wouldn't surprise me in the least if someone were to put a CLAT in a CPE, either.

> Not sure I understand what you mean here. Did you mean "the server 
> won't know what to do with the literal IPv6 address the client asks it 
> to connect to"?

Looked a bit more into it, and I think FTP was a poor example. It works when the client is on IPv6. It's worse if the client is on IPv4 and accessing an IPv6 server through SIIT; but it works again with if you use dual translation so the server thinks it's on IPv4 too.

Anyway, I suppose it would be better to ask the Orange Poland guys, they should know best which specific application problems they ran into with
464XLAT+DNS64 that caused them to forego DNS64.

Tore

EE Limited

---

From: <[email-masked]>
Date: Thu, 25 Sep 2014 08:41:21 +0000

Hi Nick,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : v6ops [mailto:[email-masked]] De la part de Heatley, Nick
>Envoyé : jeudi 25 septembre 2014 10:32
>À : Tore Anderson; Lorenzo Colitti; Metschulat, Holger
>([email-masked])
>WG

[Med] Seems like you would agree with the conclusions in http://tools.ietf.org/html/rfc6889

---

From: "Heatley, Nick" <[email-masked]>
Date: Thu, 25 Sep 2014 09:35:36 +0000

I didn't even know that doc existed :-)
I always thought that something was missing!
Thanks for the steer!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 25 September 2014 09:41
To: Heatley, Nick; Tore Anderson; Lorenzo Colitti; Metschulat, Holger ([email-masked])
Cc: [email-masked]; [email-masked] WG
Subject: RE: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Hi Nick,

Please see inline.

Cheers,
Med

>Envoyé : jeudi 25 septembre 2014 10:32 À : Tore Anderson; Lorenzo 
>Colitti; Metschulat, Holger
>Cc : [email-masked]; 
>[email-masked] WG Objet : Re: [v6ops] new draft: 
>draft-wang-v6ops-xlat-prefix-discovery
>

EE Limited

---

From: <[email-masked]>
Date: Thu, 25 Sep 2014 11:40:09 +0200

Von: v6ops [mailto:[email-masked]] Im Auftrag von Lorenzo Colitti
Gesendet: Mittwoch, 24. September 2014 17:33
An: Tore Anderson
Cc: [email-masked]; [email-masked] WG
Betreff: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

> Not sure I understand what you mean here. Did you mean "the server won't know what to do with the literal IPv6 address the client asks
> it to connect to"?

No, Tore meant the IPv4 address that the FTP server will return after the client issued the PASV command. However, an IPv6 client will never use the PASV command.

In passive FTP with IPv6, the IPv6 client will not use the PASV command, but the EPSV command. This will not return the address of the server, but just the port number (see RFC2428 and RFC6384):

$ lftp -d ftp.mathematik.tu-darmstadt.de<ftp://ftp.mathematik.tu-darmstadt.de> # <-- this is an IPv4-only FTP server
lftp ftp.mathematik.tu-darmstadt.de:~> ls
---- Connecting to ftp.mathematik.tu-darmstadt.de (64:ff9b::8253:21a) port 21
`ls' at 0 [Connecting...]
<--- 220 ProFTPD 1.3.3a Server (ftp.mathematik.tu-darmstadt.de) [130.83.2.26]
...
---> EPSV
<--- 229 Entering Extended Passive Mode (|||39900|)
---- Connecting data socket to (64:ff9b::8253:21a) port 39900
---- Data connection established
...

So the FTP ALG on the NAT64 box will have to translate from EPSV to PASV vice versa if the IPv4-only FTP server does not understand the EPSV command natively.

Holger

---

From: <[email-masked]>
Date: Thu, 25 Sep 2014 11:00:22 +0000

Re-,

Now you are ;-)

Another document that I recommend to read is: Issues with IP Address Sharing (http://tools.ietf.org/html/rfc6269). This one discusses issues common to all address sharing scheme including NAT44, NAT64, DS-Lite, MAP-*, etc.

Cheers,
Med

>De : Heatley, Nick [mailto:[email-masked]]
>Envoyé : jeudi 25 septembre 2014 11:36
>À : BOUCADAIR Mohamed IMT/OLN; Tore Anderson; Lorenzo Colitti; Metschulat,
>Holger ([email-masked])
>Objet : RE: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery
>

---

From: Czerwonka Michał 1 - Hurt <[email-masked]>
Date: Fri, 26 Sep 2014 12:17:35 +0000

OPL use APN IPv6-only for all services we have, but some mobile operators use different APN for tethering. Why ?

if we apply the architecture CLAT+PLAT+DNS we can achieve quality of service like in DS, with DNS64 NOT.

BR,
Mcz

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Heatley, Nick
Sent: Thursday, September 25, 2014 10:32 AM
To: Tore Anderson; Lorenzo Colitti; Metschulat, Holger ([email-masked])
Cc: [email-masked]; [email-masked] WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

There appear to be two schools of thought around the NAT64 in the 464xlat:
1. run NAT64 as dumb as possible, don't look to use ALGs, prefer double translations to hide upper layer issues 2. try to achieve parity between NAT64 and NAT44 in terms of ALGs and session helpers supported, then allow single translations over double translations

Holger gave a scenario behind camp1 thinking - a mixed environment of dual stack / IPv6-only devices.
However looking deeper, does it further depends if you have public IPv4 or private IPv4 for the dual stack.
If you are in camp 1, absence of DNS64, and you use public IPv4 you may avoid NAT altogether on the IPv4 dual stack path (otherwise synthesised IPv6 destinations will take pref over IPv4).
(=> enough public IPv4 for dual stack cellular devices, lucky you!) If you accept that your dual stack devices will be using private IPv4 then it really is down to whether the NAT64 path from DNS64 can match NAT44 IMHO. (i.e. has your NAT64 vendor written those ALGs yet...)

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Tore Anderson
Sent: 24 September 2014 18:07
To: Lorenzo Colitti
Cc: [email-masked]; [email-masked] WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

* Lorenzo Colitti

Tore

EE Limited

---

From: Ross Chandler <[email-masked]>
Date: Fri, 26 Sep 2014 21:25:07 +0100

> OPL use APN IPv6-only for all services we have, but some mobile operators use different APN for tethering. Why ?

Cynical hat on. It is a way of claiming an unlimited data plan while blocking the main way of downloading a lot.

Ross

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 28 Sep 2014 12:47:25 +0900

Can you provide examples of what does not work with DNS64?

In fact, that would be useful to document in an informational document.

On Fri, Sep 26, 2014 at 9:17 PM, Czerwonka Michał 1 - Hurt <
[email-masked]> wrote:

> 1. run NAT64 as dumb as possible, don't look to use ALGs, prefer double
> translations to hide upper layer issues 2. try to achieve parity between
> NAT64 and NAT44 in terms of ALGs and session helpers supported, then allow
> single translations over double translations
>
> If you are in camp 1, absence of DNS64, and you use public IPv4 you may
> avoid NAT altogether on the IPv4 dual stack path (otherwise synthesised
> IPv6 destinations will take pref over IPv4).
> (=> enough public IPv4 for dual stack cellular devices, lucky you!) If you
> accept that your dual stack devices will be using private IPv4 then it
> really is down to whether the NAT64 path from DNS64 can match NAT44 IMHO.
> (i.e. has your NAT64 vendor written those ALGs yet...)
>
> I am happy with FTP now that we modified the behaviour of our NAT64
> firewall (allow PASV over IPv6 transport).
> The other aspect in the mix is the existence of pre-RFC2428 FTP servers
> (some 50% of internet FTP servers allegedly), which makes FTP quite special
> and interesting for translation behaviour.
>
> I guess I am in camp 2, I believe my NAT64 is as good as my NAT44 (with
> the proviso that testing is ongoing...), and you will never solve complex
> or higher layer issues, like active FTP, without resorting to ALGs.
> Maybe you already have boxes already capable of NAT64 lying around, and no
> room on your budgets for new MAP boxes? I don't know...you could say the
> same thing about DS-Lite, but people are deploying that, too. So it
> wouldn't surprise me in the least if someone were to put a CLAT in a CPE,
> either.
>
> accessing an IPv6 server through SIIT; but it works again with if you use
> dual translation so the server thinks it's on IPv4 too.
>
> This e-mail (including any attachments) is intended for the above-named
> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or use
> for any purpose.
>
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachments
> are free from any virus, but it remains your responsibility to ensure that
> viruses do not adversely affect you.
>
> EE Limited