Subject: [v6ops] NAT64+DNS64

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 Nov 2010 12:57:00 +0100 (CET)

Hello.

We're mucking around with DNS64+NAT64 for Mobile applications. I have a 
Nokia N900 enabled for IPv6 by using 
<https://code.google.com/p/n900ipv6/wiki/README> information.

The behaviour I'm seeing is that the N900 asks for both A and AAAA records 
from the DNS64 device. The DNS64 device only acts on AAAA queries, and 
answers A queries unchanged (as it should according to DNS64 draft). The 
N900 then seems to load share between A and AAAA, and of course failing 
all IPv4 TCP sessions due to not having any IPv4 default route. This means 
for instance an "apt-get" fails on approximately half the files it tries 
to get. It also means "www.engadget.com" doesn't work. Some other web 
pages work for some reason, yet others do not. I haven't really been able 
to figure out exactly why some things work and some others don't.

I've failed to locate a standard specifying what an application should 
actually do when receiving multiple A and AAAA records. "telnet" on a 
linux machine will try them all in some order. This was my impression was 
the standard behaviour, but I can't find any RFC actually saying this is 
the recommended/mandated way.

So the main question: Where does it say that an application should try all 
AAAA and A records before failing?

I have yet to try DNS64+NAT64 on other platforms, will see if they work 
better.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 10 Nov 2010 20:10:27 +0800

Le 10-11-10 19:57, Mikael Abrahamsson a écrit :
> The behaviour I'm seeing is that the N900 asks for both A and AAAA
> records from the DNS64 device. The DNS64 device only acts on AAAA
> queries, and answers A queries unchanged (as it should according to
> DNS64 draft). The N900 then seems to load share between A and AAAA,

- does the access network ipv6-only? i.e. no ipv4 addresses, ...
- if ipv6-only, then the stack should not be asking A records.
- this behavior is known for other OS stacks.

some OS stacks have not been yet made to function correctly in v6only 
environments, which is the basic assumptions of the nat64/dns64.

> and
> of course failing all IPv4 TCP sessions due to not having any IPv4
> default route. This means for instance an "apt-get" fails on
> approximately half the files it tries to get. It also means
> "www.engadget.com" doesn't work. Some other web pages work for some
> reason, yet others do not. I haven't really been able to figure out
> exactly why some things work and some others don't.
>
> actually do when receiving multiple A and AAAA records.

- choice of application programmer.
- recommended practice up to now was to cycle through the records you 
receive and try a connect until you have one connect successful
- others, for performance reasons (i.e. decrease as much as possible the 
delay until successful connect) do queries and connects all in parallel. 
the first successful connect wins.

> "telnet" on a
> linux machine will try them all in some order. This was my impression
> was the standard behaviour, but I can't find any RFC actually saying
> this is the recommended/mandated way.
>
> So the main question: Where does it say that an application should try
> all AAAA and A records before failing?
>

yes, some platforms behave better. some are similar to what you have seen.

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 Nov 2010 13:29:05 +0100 (CET)

> - does the access network ipv6-only? i.e. no ipv4 addresses, ...

Only IPv4 address is 127.0.0.1/8 on lo.

> - if ipv6-only, then the stack should not be asking A records.

Correct, but it asks for A anyway. Removing IPv4 address (127.0.0.1/8) 
means more things break because I guess it takes for granted lo should be 
there.

> - recommended practice up to now was to cycle through the records you receive 
> and try a connect until you have one connect successful
> delay until successful connect) do queries and connects all in parallel. the 
> first successful connect wins.

Is this written down somewhere? If not, what WG should handle this?

> yes, some platforms behave better. some are similar to what you have 

*sigh*

Well, put me down on the camp that demands ds.lite at least, the world is 
not generally ready for IPv6 only. XP won't work, lots of mobile OSes 
won't work, most connection managers doesn't accept not getting IPv4 
address (ubuntu for instance).

---

From: Tore Anderson <[email-masked]>
Date: Wed, 10 Nov 2010 14:08:43 +0100

* Mikael Abrahamsson

> DNS64 draft). The N900 then seems to load share between A and AAAA, and

Hi Mikael,

The behaviour on what to try and in what order is defined in RFC 3484.
I'm guessing that the N900 does not implement it (or that some of its
applications do not use the RFC 3484-compliant interfaces).

Assuming that both the destination and your N900 have native IPv6
addresses, a number of rules in the destination address selection
algorithm would have prevented IPv4 from being preferred over IPv6,
including:

Rule 1, as you don't have a route to the IPv4 destination address.
Rule 2, as 127.0.0.1 won't match the destination address scope, while
the IPv6 source addresses does.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27

---

From: Tore Anderson <[email-masked]>
Date: Wed, 10 Nov 2010 14:24:08 +0100

Hi again,

* Mikael Abrahamsson

> Correct, but it asks for A anyway. Removing IPv4 address
> (127.0.0.1/8) means more things break because I guess it takes for
> granted lo should be there.

The proper way to do this is as far as I know is for an application to
call getaddrinfo() with the AI_ADDRCONFIG hint, which optimizes away A
or AAAA queries if their results would be unusable anyway.

> most connection managers doesn't accept not getting IPv4 address
> (ubuntu for instance).

Yes, this is a major PITA.  The sad thing is that everything is already
implemented, all it takes is for the setting that says IPv4 is required
for success to change so it defaults to off.  Any help convincing the
developer at <https://bugzilla.redhat.com/show_bug.cgi?id=538499> would
be much appreciated.

By the way, you might want to get in touch with Cameron Byrne from
T-Mobile about your experiences.  As far as I know they're running a
NAT64/DNS64 trial too and have had great success with it.  See
<http://www.youtube.com/watch?v=1GlRgaFriYU#t=15m38s>.

Best regards,

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 10 Nov 2010 06:13:26 -0800

On Wed, Nov 10, 2010 at 4:29 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Correct, but it asks for A anyway. Removing IPv4 address (127.0.0.1/8) means
> more things break because I guess it takes for granted lo should be there.
>
> not generally ready for IPv6 only. XP won't work, lots of mobile OSes won't
> work, most connection managers doesn't accept not getting IPv4 address
> (ubuntu for instance).

Thanks for checking in so we can get you setup right.  I have not seen
this issue you have before.  But,  I have nearly 100 folks with n900
on my network, most of them ipv6-only,  and there are several tips and
tricks and implementation reports here

http://talk.maemo.org/showthread.php?t=60320

This one is especially helpful

http://talk.maemo.org/showpost.php?p=813799&postcount=128

I am sure there are some folks from Nokia on the list that might be
able to give you some expert advise on your issue.... but, i can
assure you that for most applications, the N900 does works in
IPv6-only.  Failure to work with IPv6 is an exception, not the common
place in my Nokia experience.  That said, Symbian works much better
with IPv6-only than Maemo today (excluding the current N8),...... but
as you know, Maemo is dead, Meego is rising.  Hopefully the new Meego
will actually be new and not carry legacy ipv4 only baggage.

I remain optimistic about the address agnostic nature of iOS and
Android, once support is added on the cellular interface... but i have
heard good reports of testing ipv6-only on the wifi.  DS.lite seems to
be a sledge hammer solution to a problem with a few mobile apps,
better to force the apps to get fixed.  DS.lite is great for fixed
line, but i believe it has been fully rejected by the mobile
community.

Cameron

---

From: Thomas Habets <[email-masked]>
Date: Wed, 10 Nov 2010 15:22:53 +0100 (CET)

> The behaviour on what to try and in what order is defined in RFC 3484.

While it does define the order (section 6), it doesn't seem to define how 
to process the list of valid addresses.

Should it try the next address even if it doesn't have routing to the
destination? (how does the app know?) How about if it times out when 
trying to connect? How about if it gets connection refused, or admin 
prohibited? What if it's just a temporary error? (EAGAIN, EINTR)

Cameron Byrne <[email-masked]> wrote:
> I remain optimistic about the address agnostic nature of iOS

They "have no plans" for v6 on cellular for iPhone.

Step 1: Launch a product in 2010 with no plans for ipv6.
Step 2: Profit
Step 3: Profit
Step 4: Profit

---------
typedef struct me_s {
   char name[]      = { "Thomas Habets" };
   char email[]     = { "[email-masked]" };
   char kernel[]    = { "Linux" };
   char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
   char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE  0945 286A E90A AD48 E854" };
   char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

---

From: Tore Anderson <[email-masked]>
Date: Wed, 10 Nov 2010 15:42:15 +0100

Hi,

* Thomas Habets

> While it does define the order (section 6), it doesn't seem to
> define how to process the list of valid addresses.

>From section 2:

   Well-behaved applications SHOULD iterate through the list of
   addresses returned from getaddrinfo() until they find a working
   address.

> Should it try the next address even if it doesn't have routing to
> the destination? (how does the app know?)

Yes.  It will know because connect() will fail.  Besides, if there's no
route to a specific destination address, it should be last in line for
connection attempts as per destination address selection rule 1.

> How about if it times out when trying to connect? How about if it
> gets connection refused, or admin prohibited? What if it's just a
> temporary error? (EAGAIN, EINTR)

This is left up to the implementor, I guess.  But all implementations
I've seen move on to the next address if connect() fails for whatever
reason.

In any case, the arbitrary «load sharing» behaviour described by Mikael
should never occur.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 10 Nov 2010 06:46:03 -0800

On Wed, Nov 10, 2010 at 6:22 AM, Thomas Habets <[email-masked]> wrote:
> While it does define the order (section 6), it doesn't seem to define how to
> process the list of valid addresses.
>
> destination? (how does the app know?) How about if it times out when trying
> to connect? How about if it gets connection refused, or admin prohibited?
> What if it's just a temporary error? (EAGAIN, EINTR)
>

Yes, it is frustrating that they don't have plans to share, but none
of the handset vendors have solid roadmaps they choose to share.  We
have no guidance on Meego, Android, or even Maemo .... it is not
officially supported, but works.  I have a hard time believing they
have no plans, and i have heard via informal channels, rumors that
they have tested 3G IPv6 already with a carrier.  You can file that in
the rumor category.

> Step 1: Launch a product in 2010 with no plans for ipv6.

As James has pointed out, Apple has been pretty good about
successively introducing more and more IPv6 features across all their
products. My guess is that step 5 is launch a product in 2011 or 2012
with IPv6, repeat steps 2 - 4.

Cameron

---

From: Thomas Habets <[email-masked]>
Date: Wed, 10 Nov 2010 16:35:41 +0100 (CET)

On Wed, 10 Nov 2010, Cameron Byrne wrote:
> of the handset vendors have solid roadmaps they choose to share.

Nokia has been very open I think:
<http://docs.google.com/viewer?a=v&q=cache:5rA1cKkgcd4J:72.34.43.90/IPV6/usipv6_reston_2004/fri/Danz.pdf+&hl=en&pid=bl&srcid=ADGEEShlpj0MS8MJjwzUTdlalzHKJ4TiFccZ4UCTyyHw8lkwNADnwl3N16fHnJ9_yVjiEr0Rb5B8XHn_Unho1k2fl2fWwfXnVBa6_gYO86p-PEOPHzt7PzeP4UMMfhuWvuOhvbhWpDLo&sig=AHIEtbRHfgMaXjPoQ8eZBNeZXXNKLzSnQg>
and others.

---------
typedef struct me_s {

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 10 Nov 2010 16:23:16 +0000 (UTC)

On Wed, 10 Nov 2010, Mikael Abrahamsson wrote:

> *sigh*
>
> Well, put me down on the camp that demands ds.lite at least, the world is not 
> generally ready for IPv6 only. XP won't work

What's the problem with that, or do you just mean "does not work out
of the box as you plug the cable in"?  Please be more specific to the
issues you are seeing in a v6 only environment after manual
configuration?

/bz

-- 
Bjoern A. Zeeb                              Welcome a new stage of life.
         <ks> Going to jail sucks -- <bz> All my daemons like it!
   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html

---

From: <[email-masked]>
Date: Fri, 12 Nov 2010 15:13:09 +0100

Sorry for noticing this only now that it is too late to repeat the test in the IETF network.

The IPv6 in N900 is what Linux kernel version 2.6.28 provides. I have seen it working just fine in IPv6 + NAT64 cellular accesses without issues you describe. However, I don't recall personally trying it out in an IPv6-only WLAN with NAT64.. Yes it may send both A and AAAA queries, but it sounds odd that it would actually try to communicate with IPv4 without any IPv4 address configured on its interfaces..

Hence more information is needed to help you out - please feel free to send email offlist. 

Generally, the IPv6 for N900 is there for people to experience IPv6 (especially on cellular networks), not as a commercial feature. (Just to make sure everyone's expectations are right).

Best regards,

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Mikael Abrahamsson
> Sent: 10. marraskuuta 2010 19:57
> To: [email-masked]
> Subject: [v6ops] NAT64+DNS64
> 
> 
> Hello.
> 
> records
> was
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Nov 2010 15:34:47 +0100 (CET)

On Fri, 12 Nov 2010, [email-masked] wrote:

> The IPv6 in N900 is what Linux kernel version 2.6.28 provides. I have 
> seen it working just fine in IPv6 + NAT64 cellular accesses without 
> issues you describe. However, I don't recall personally trying it out in 
> an IPv6-only WLAN with NAT64.. Yes it may send both A and AAAA queries, 
> but it sounds odd that it would actually try to communicate with IPv4 
> without any IPv4 address configured on its interfaces..

This was IPv6 only cellular.

I've had some weird problems with IPv6 before as well, so I'm going to 
reflash the device just to make sure. I bought it back in december 2009 so 
all the upgrades since then might have caused some problems. I'll reply 
again after I've done that and show my experiences.

We've done some testing with Nokia E71 (symbian) without the problems I'm 
seeing on the N900 so it's most likely something weird with my N900.

---

From: <[email-masked]>
Date: Mon, 15 Nov 2010 15:44:42 +0100

It seems the problem seen with N900 is caused by a bug in DNS64's synthetic AAAA reply, which causes some (stricter) clients to ignore the AAAA reply, while some (less strict) clients accepted it. In this case the source address selection logic on N900 got into situation with IPv6-only source addresses but IPv4-only destination addresses...

Will let you know once we've had change to retest this with a fixed DNS64 (the bug is fixed but not yet released).

Best regards,

	Teemu

> Of ext Cameron Byrne
> Sent: 10. marraskuuta 2010 16:13
> To: Mikael Abrahamsson
> Cc: [email-masked]
> Subject: Re: [v6ops] NAT64+DNS64
> 
> (127.0.0.1/8) means
> won't

---

From: [email-masked]
Date: Mon, 15 Nov 2010 17:05:58 +0200

Had the same issues during the tests. As Teemu said, it is related to a 
bug in DNS64. The behavior you have observed is related to CNAME 
generation. Random Linux systems will fail to properly understand the 
"trunkated" answer from the DNS64 that does not behave according to the 
specifications. This is what explains that some sites work and others 
don't. Those that don't work will have CNAMEs. Those that do, have A 
records only.  When the answer is received from a DNS64 that does not have 
the entire CNAME list, the client apparently discards the answer and will 
attempt to connect to A record alone, even if it does not have IPv4. It 
does not seem to be related to a specific Kernel, as some version of 
Fedora for instance work OK, and others fail. Ubuntu fails on all versions 
I have tried.

Best,
Roman

From:   <[email-masked]>
To:     <[email-masked]>, <[email-masked]>
Cc:     [email-masked]
Date:   15-11-10 16:45
Subject:        Re: [v6ops] NAT64+DNS64
Sent by:        [email-masked]

It seems the problem seen with N900 is caused by a bug in DNS64's 
synthetic AAAA reply, which causes some (stricter) clients to ignore the 
AAAA reply, while some (less strict) clients accepted it. In this case the 
source address selection logic on N900 got into situation with IPv6-only 
source addresses but IPv4-only destination addresses...

Will let you know once we've had change to retest this with a fixed DNS64 
(the bug is fixed but not yet released).

Best regards,

Teemu

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Nov 2010 16:18:32 -0800

On Nov 10, 2010, at 3:57 AM, Mikael Abrahamsson wrote:

> So the main question: Where does it say that an application should try all AAAA and A records before failing?

The standard doesn't say that. That said, one does wonder why an application would declare a failure to communicate before it had tried all of the available addresses...

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 23 Nov 2010 06:20:00 +0100 (CET)

On Mon, 22 Nov 2010, Fred Baker wrote:

> The standard doesn't say that. That said, one does wonder why an 
> application would declare a failure to communicate before it had tried 
> all of the available addresses...

Well, my, point is that since it doesn't say anywhere, I guess there is 
risk for different programs behaving differently because the programmers 
interpreted things differently.

If I remember correctly (10+ years ago), Microsoft Exchange would for 
instance handle multiple MXes just fine, but it would just connect to the 
first A record for each MX, meaning some using single MX with multiple As, 
would not work if the first one tried didn't work (regardless if it was 
because of timeout or connection refused).

Also, since a lot of programs is going to be converted to dual stack now 
(I'm afraid a lot of software is still being written with v4 only APIs), 
wouldn't it make sense to publish example code (for different OSes) that 
does the right thing as an informational document?

I don't have the knowledge to do it myself, but perhaps someone here does?

---

From: [email-masked]
Date: Tue, 23 Nov 2010 07:31:04 +0200

Fred,

As it has been previously mentioned, it is related to the way the 
application works. In case with NAT64 implementation, that has been 
observed to not behave as it exactly should, the client would query for 
both A and AAAA records. In case the DNS returns an IPv6 address as part 
of the query for a specific site, it will work. In case CNAMEs will be 
returned for the A query they will be delivered completely, in case CNAMEs 
are returned for AAAA, it will not contain the entire CNAME list. In the 
end, the client, somehow knowing that the things are wrong simply ignores 
the IPv6 CNAME and goes for IPv4 CNAME. But, in case with mobile and NAT64 
the client obviously does not have an IPv4 address, so it fails. So, it is 
not the issue of probing, but rather application behavior.

As per Cameron words, he did not observe this behavior, so we can conclude 
it is just related to some implementations.

Best,
Roman

From:   Fred Baker <[email-masked]>
To:     Mikael Abrahamsson <[email-masked]>
Cc:     [email-masked]
Date:   23-11-10 02:19
Subject:        Re: [v6ops] NAT64+DNS64
Sent by:        [email-masked]

The standard doesn't say that. That said, one does wonder why an 
application would declare a failure to communicate before it had tried all 
of the available addresses...
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops