new draft: draft-wang-v6ops-xlat-prefix-discovery

Discussion:

f***@public.gmane.org

2014-09-19 11:47:01 UTC

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.

Andrew 👽 Yourtchenko

2014-09-19 16:41:16 UTC

Permalink

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

Lishan Li

2014-09-24 11:27:56 UTC

Permalink

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

Post by Andrew ð½ Yourtchenko
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
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

_______________________________________________
v6ops mailing list
https://www.ietf.org/mailman/listinfo/v6ops

Lorenzo Colitti

2014-09-24 11:37:20 UTC

Permalink

Post by Lishan Li
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.

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.

Lishan Li

2014-09-24 12:24:20 UTC

Permalink

Dear Lorenzo,

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

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" <***@google.com> åéïŒ

On Wed, Sep 24, 2014 at 8:27 PM, Lishan Li <***@126.com> 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.

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.

Lorenzo Colitti

2014-09-24 12:30:14 UTC

Permalink

Post by Lishan Li
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âŠ

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

h***@public.gmane.org

2014-09-24 12:44:00 UTC

Permalink

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:v6ops-***@ietf.org] Im Auftrag von Lishan Li
Gesendet: Mittwoch, 24. September 2014 14:24
An: Lorenzo Colitti
Cc: draft-wang-v6ops-xlat-prefix-***@tools.ietf.org; ***@ietf.org WG
Betreff: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Dear Lorenzo,

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

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" <***@google.com<mailto:***@google.com>> åéïŒ

On Wed, Sep 24, 2014 at 8:27 PM, Lishan Li <***@126.com<mailto:***@126.com>> 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.

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.

Tore Anderson

2014-09-24 12:51:26 UTC

Permalink

* Lorenzo Colitti

Post by Lorenzo Colitti
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.

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

Lorenzo Colitti

2014-09-24 13:02:18 UTC

Permalink

Post by Tore Anderson

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?

h***@public.gmane.org

2014-09-24 13:38:05 UTC

Permalink

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

Tore Anderson

2014-09-24 15:23:26 UTC

Permalink

Post by 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.

Post by Lorenzo Colitti
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".

Good point.

Post by Lorenzo Colitti
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?

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

Lorenzo Colitti

2014-09-24 15:32:54 UTC

Permalink

Post by Tore Anderson

Post by 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.

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

Post by Tore Anderson
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)

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"?

Tore Anderson

2014-09-24 17:07:27 UTC

Permalink

* Lorenzo Colitti

Post by 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.

Post by Lorenzo Colitti
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"?

Heatley, Nick

2014-09-25 08:32:28 UTC

Permalink

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:v6ops-bounces-***@public.gmane.org] On Behalf Of Tore Anderson
Sent: 24 September 2014 18:07
To: Lorenzo Colitti
Cc: draft-wang-v6ops-xlat-prefix-discovery-nZLwadvX8BDR74oF6e/***@public.gmane.org; v6ops-***@public.gmane.org WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

* Lorenzo Colitti

Post by 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.

Post by Lorenzo Colitti
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

_______________________________________________
v6ops mailing list
v6ops-***@public.gmane.org
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

m***@public.gmane.org

2014-09-25 08:41:21 UTC

Permalink

Hi Nick,

Please see inline.

Cheers,
Med

-----Message d'origine-----
Envoyé : jeudi 25 septembre 2014 10:32
À : Tore Anderson; Lorenzo Colitti; Metschulat, Holger
WG
Objet : Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery
Until someone shows why NAT64 cannot equal NAT44 in service experience, I
am placing my bets on NAT64 ALGs.

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

Heatley, Nick

2014-09-25 09:35:36 UTC

Permalink

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

-----Original Message-----
From: mohamed.boucadair-C0LM0jrOve7QT0dZR+***@public.gmane.org [mailto:mohamed.boucadair-C0LM0jrOve7QT0dZR+***@public.gmane.org]
Sent: 25 September 2014 09:41
To: Heatley, Nick; Tore Anderson; Lorenzo Colitti; Metschulat, Holger (holger.metschulat-+tb+***@public.gmane.org)
Cc: draft-wang-v6ops-xlat-prefix-discovery-nZLwadvX8BDR74oF6e/***@public.gmane.org; v6ops-***@public.gmane.org WG
Subject: RE: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Hi Nick,

Please see inline.

Cheers,
Med

-----Message d'origine-----
Envoyé : jeudi 25 septembre 2014 10:32 À : Tore Anderson; Lorenzo
Colitti; Metschulat, Holger
draft-wang-v6ops-xlat-prefix-discovery
Until someone shows why NAT64 cannot equal NAT44 in service experience,
I am placing my bets on NAT64 ALGs.

[Med] Seems like you would agree with the conclusions in http://tools.ietf.org/html/rfc6889
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

m***@public.gmane.org

2014-09-25 11:00:22 UTC

Permalink

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

-----Message d'origine-----
Envoyé : jeudi 25 septembre 2014 11:36
À : BOUCADAIR Mohamed IMT/OLN; Tore Anderson; Lorenzo Colitti; Metschulat,
WG
Objet : RE: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery
I didn't even know that doc existed :-)
I always thought that something was missing!
Thanks for the steer!
-----Original Message-----
Sent: 25 September 2014 09:41
To: Heatley, Nick; Tore Anderson; Lorenzo Colitti; Metschulat, Holger
WG
Subject: RE: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery
Hi Nick,
Please see inline.
Cheers,
Med

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

Czerwonka Michał 1 - Hurt

2014-09-26 12:17:35 UTC

Permalink

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:v6ops-bounces-***@public.gmane.org] On Behalf Of Heatley, Nick
Sent: Thursday, September 25, 2014 10:32 AM
To: Tore Anderson; Lorenzo Colitti; Metschulat, Holger (holger.metschulat-+tb+***@public.gmane.org)
Cc: draft-wang-v6ops-xlat-prefix-discovery-nZLwadvX8BDR74oF6e/***@public.gmane.org; v6ops-***@public.gmane.org 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

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:v6ops-bounces-***@public.gmane.org] On Behalf Of Tore Anderson
Sent: 24 September 2014 18:07
To: Lorenzo Colitti
Cc: draft-wang-v6ops-xlat-prefix-discovery-nZLwadvX8BDR74oF6e/***@public.gmane.org; v6ops-***@public.gmane.org WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

* Lorenzo Colitti

Post by 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.

Post by Lorenzo Colitti
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"?

Ross Chandler

2014-09-26 20:25:07 UTC

Permalink

Post by Czerwonka MichaÅ 1 - Hurt
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

Lorenzo Colitti

2014-09-28 03:47:25 UTC

Permalink

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 <

Post by Czerwonka MichaÅ 1 - Hurt
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-----
Sent: Thursday, September 25, 2014 10:32 AM
To: Tore Anderson; Lorenzo Colitti; Metschulat, Holger (
WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery
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...)
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-----
Sent: 24 September 2014 18:07
To: Lorenzo Colitti
WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery
* Lorenzo Colitti

Post by 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.

Post by Lorenzo Colitti
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
_______________________________________________
v6ops mailing list
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
_______________________________________________
v6ops mailing list
https://www.ietf.org/mailman/listinfo/v6ops

Czerwonka Michał 1 - Hurt

2014-10-01 09:37:52 UTC

Permalink

http://forum.ea.com/eaforum/posts/list/9741229.page

maybe is more application like this above.

BR,
Mcz

From: Lorenzo Colitti [mailto:***@google.com]
Sent: Sunday, September 28, 2014 5:47 AM
To: Czerwonka MichaÅ 1 - Hurt
Cc: Heatley, Nick; Tore Anderson; Metschulat, Holger (***@telekom.de); draft-wang-v6ops-xlat-prefix-***@tools.ietf.org; ***@ietf.org WG; Kossut Tomasz - Hurt
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

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 <***@orange.com<mailto:***@orange.com>> wrote:
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

Ross Chandler

2014-10-01 16:52:40 UTC

Permalink

Is this an issue only seen from tethered hosts in the 64share/RFC 7278 case or have you also seen apps on the UE with the problem?

BR
Ross

Post by Czerwonka MichaÅ 1 - Hurt
http://forum.ea.com/eaforum/posts/list/9741229.page
maybe is more application like this above.
BR,
Mcz
Sent: Sunday, September 28, 2014 5:47 AM
To: Czerwonka MichaÅ 1 - Hurt
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery
Can you provide examples of what does not work with DNS64?
In fact, that would be useful to document in an informational document.
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
_______________________________________________
v6ops mailing list
https://www.ietf.org/mailman/listinfo/v6ops

Czerwonka Michał 1 - Hurt

2014-10-02 09:45:45 UTC

Permalink

Origin client run on PC with windows only, so itâs tethering.

BR,
Mcz

From: Ross Chandler [mailto:***@eircom.net]
Sent: Wednesday, October 01, 2014 6:53 PM
To: Czerwonka MichaÅ 1 - Hurt
Cc: Lorenzo Colitti; ***@ietf.org WG; draft-wang-v6ops-xlat-prefix-***@tools.ietf.org; Tore Anderson; Kossut Tomasz - Hurt
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Is this an issue only seen from tethered hosts in the 64share/RFC 7278 case or have you also seen apps on the UE with the problem?

BR
Ross

On 1 Oct 2014, at 10:37, Czerwonka MichaÅ 1 - Hurt <***@orange.com<mailto:***@orange.com>> wrote:

http://forum.ea.com/eaforum/posts/list/9741229.page

maybe is more application like this above.

BR,
Mcz

From: Lorenzo Colitti [mailto:***@google.com]
Sent: Sunday, September 28, 2014 5:47 AM
To: Czerwonka MichaÅ 1 - Hurt
Cc: Heatley, Nick; Tore Anderson; Metschulat, Holger (***@telekom.de<mailto:***@telekom.de>); draft-wang-v6ops-xlat-prefix-***@tools.ietf.org<mailto:draft-wang-v6ops-xlat-prefix-***@tools.ietf.org>; ***@ietf.org<mailto:***@ietf.org> WG; Kossut Tomasz - Hurt
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

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 <***@orange.com<mailto:***@orange.com>> wrote:
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

_______________________________________________
v6ops mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops

Heatley, Nick

2014-10-06 09:07:48 UTC

Permalink

Can I ask, was the problem seen when 464xlat/NAT64 external IPv4 address was the same as DNS64/NAT64 external IPv4? I.e. NAT64 hash is only on IPv6 prefix?
Thanks.

From: v6ops [mailto:v6ops-***@ietf.org] On Behalf Of Czerwonka Michal 1 - Hurt
Sent: 02 October 2014 10:46
To: Ross Chandler
Cc: ***@ietf.org WG; Tore Anderson; draft-wang-v6ops-xlat-prefix-***@tools.ietf.org; Kossut Tomasz - Hurt
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Origin client run on PC with windows only, so itâs tethering.

BR,
Mcz

From: Ross Chandler [mailto:***@eircom.net]
Sent: Wednesday, October 01, 2014 6:53 PM
To: Czerwonka MichaÅ 1 - Hurt
Cc: Lorenzo Colitti; ***@ietf.org<mailto:***@ietf.org> WG; draft-wang-v6ops-xlat-prefix-***@tools.ietf.org<mailto:draft-wang-v6ops-xlat-prefix-***@tools.ietf.org>; Tore Anderson; Kossut Tomasz - Hurt
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Is this an issue only seen from tethered hosts in the 64share/RFC 7278 case or have you also seen apps on the UE with the problem?

BR
Ross

On 1 Oct 2014, at 10:37, Czerwonka MichaÅ 1 - Hurt <***@orange.com<mailto:***@orange.com>> wrote:

http://forum.ea.com/eaforum/posts/list/9741229.page

maybe is more application like this above.

BR,
Mcz

From: Lorenzo Colitti [mailto:***@google.com]
Sent: Sunday, September 28, 2014 5:47 AM
To: Czerwonka MichaÅ 1 - Hurt
Cc: Heatley, Nick; Tore Anderson; Metschulat, Holger (***@telekom.de<mailto:***@telekom.de>); draft-wang-v6ops-xlat-prefix-***@tools.ietf.org<mailto:draft-wang-v6ops-xlat-prefix-***@tools.ietf.org>; ***@ietf.org<mailto:***@ietf.org> WG; Kossut Tomasz - Hurt
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

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 <***@orange.com<mailto:***@orange.com>> wrote:
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

_______________________________________________
v6ops mailing list
***@ietf.org<mailto:***@ietf.org>
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

h***@public.gmane.org

2014-09-25 09:40:09 UTC

Permalink

Von: v6ops [mailto:v6ops-***@ietf.org] Im Auftrag von Lorenzo Colitti
Gesendet: Mittwoch, 24. September 2014 17:33
An: Tore Anderson
Cc: draft-wang-v6ops-xlat-prefix-***@tools.ietf.org; ***@ietf.org 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

m***@public.gmane.org

2014-09-24 11:47:54 UTC

Permalink

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:v6ops-***@ietf.org] De la part de Lishan Li
EnvoyÃ© : mercredi 24 septembre 2014 13:28
Ã : Andrew ðœ Yourtchenko
Cc : draft-wang-v6ops-xlat-prefix-***@tools.ietf.org; ***@ietf.org
Objet : Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

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

_______________________________________________
v6ops mailing list
https://www.ietf.org/mailman/listinfo/v6ops

Lishan Li

2014-09-24 12:34:04 UTC

Permalink

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ïŒ***@orange.com åéïŒ

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:v6ops-***@ietf.org] De la part de Lishan Li
EnvoyÃ© : mercredi 24 septembre 2014 13:28
Ã : Andrew ðœ Yourtchenko
Cc :draft-wang-v6ops-xlat-prefix-***@tools.ietf.org; ***@ietf.org
Objet : Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

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

_______________________________________________
v6ops mailing list
https://www.ietf.org/mailman/listinfo/v6ops

Lorenzo Colitti

2014-09-22 15:26:15 UTC

Permalink

Post by f***@public.gmane.org
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.

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.

Bjoern A. Zeeb

2014-09-22 15:56:07 UTC

Permalink

Post by f***@public.gmane.org
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.
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.

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

Lorenzo Colitti

2014-09-22 16:52:16 UTC

Permalink

On Tue, Sep 23, 2014 at 12:56 AM, Bjoern A. Zeeb <

Post by Bjoern A. Zeeb
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.

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

Ross Chandler

2014-09-22 16:48:43 UTC

Permalink

Post by f***@public.gmane.org
, 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.

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

Heatley, Nick

2014-09-23 08:52:51 UTC

Permalink

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:v6ops-bounces-***@public.gmane.org] On Behalf Of Ross Chandler
Sent: 22 September 2014 17:49
To: Lorenzo Colitti
Cc: draft-wang-v6ops-xlat-prefix-discovery-nZLwadvX8BDR74oF6e/***@public.gmane.org; v6ops-***@public.gmane.org WG
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

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

_______________________________________________
v6ops mailing list
v6ops-***@public.gmane.org
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

Lorenzo Colitti

2014-09-23 12:05:56 UTC

Permalink

Post by Heatley, Nick
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?

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 :-)

Sander Steffann

2014-09-23 12:11:50 UTC

Permalink

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

h***@public.gmane.org

2014-09-23 06:18:10 UTC

Permalink

Hello *,

Post by f***@public.gmane.org
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.

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

Kossut Tomasz - Hurt

2014-09-23 15:05:39 UTC

Permalink

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

-----Original Message-----
From: holger.metschulat-+tb+***@public.gmane.org [mailto:holger.metschulat-+tb+***@public.gmane.org]
Sent: Tuesday, September 23, 2014 8:18 AM
To: v6ops-***@public.gmane.org
Cc: draft-wang-v6ops-xlat-prefix-discovery-nZLwadvX8BDR74oF6e/***@public.gmane.org
Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery

Hello *,

Post by f***@public.gmane.org
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.