Subject: Re: [v6ops] NAT64+DNS64

From: Fred Baker <[email-masked]>
Date: Wed, 1 Dec 2010 14:23:21 -0600

On Nov 22, 2010, at 11:20 PM, Mikael Abrahamsson wrote:

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

The Happy Eyeballs Draft actually does have one approach, which I would suggest you read. AFAIK, it is OS-specific, which says to me that for other OS's there may be different and perhaps superior approaches.

T'wer it me, and I had the commit bit on an open source stack (which I don't), I would write an API call that could be called with a name and would return either an error code or an open+connected socket, call it something obvious like "connectbyname", and encourage applications to call it. I'm not the first to have made this observation.

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Dec 2010 14:26:29 -0600

On Nov 22, 2010, at 11:31 PM, [email-masked] wrote:

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

It is OS-specific, network dependent, and due to the structure of the sockets API, application specific.

---

From: Erik Kline <[email-masked]>
Date: Wed, 1 Dec 2010 12:35:22 -0800

On 1 December 2010 12:26, Fred Baker <[email-masked]> wrote:
> As per Cameron words, he did not observe this behavior, so we can conclude
> it is just related to some implementations.
>

In Advanced Programming in the UNIX Environment, Richard Stevens
described two separate "open server" implementations:

    (1) forked, where the child passes an opened file descriptor (or
error) back to the parent over a pipe created just before the fork,
and

    (2) daemonized, where clients connect to a well-known named pipe
in the filesystem, and receive back an opened file descriptor (or
error) over that named pipe.

Any platform that supports FD passing in this classic sockets API
sense (or emulates it), can easily support this sort of thing.

Whether these implementation ideas are awesome or not, a good idea or
not, or even adequate or not, is an exercise left to the implementor.
:-)

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Dec 2010 17:46:12 -0300

Hi, Fred,

> T'wer it me, and I had the commit bit on an open source stack (which
> I don't), I would write an API call that could be called with a name
> and would return either an error code or an open+connected socket,
> call it something obvious like "connectbyname", and encourage
> applications to call it. I'm not the first to have made this
> observation.

See: http://tools.ietf.org/html/draft-gont-tcpm-tcp-soft-errors-01#section-6

At the last IETF someone (rightfully) said that the API should have a
function named "give me a f* connection" ;-) which should probably take
an URL, and return a connected socket, as you indicate.

My take with all these issues is that many of these problems have to do
with apps using APIs that are of lower level than they should be.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Dec 2010 09:49:27 +1300

> T'wer it me, and I had the commit bit on an open source stack (which I don't), I would write an API call that could be called with a name and would return either an error code or an open+connected…

Nor am I the first to point out that Java has done this for years now.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Dec 2010 17:50:44 -0300

> not, or even adequate or not, is an exercise left to the implementor.

The problem is, whoever is in charge of connection-establishment should
deal with a domainame/URL, and not with a single IP address.

If the API does not deal with domainames/URLs, the you have to implement
all the intelligence in the app, and every app has to reinvent the wheel.

That said, there's no reason for which an *app* developer should be
concerned with layer-3/4 details. e.g., why should a web developer care
about v4 vs v6 addresses and that kind of stuff?

Thanks,

---

From: Simon Perreault <[email-masked]>
Date: Wed, 01 Dec 2010 15:51:10 -0500

> Nor am I the first to point out that Java has done this for years now.

And for low-level C applications, the well-known libevent provides it also.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 03 Dec 2010 14:19:37 -0500

Teemu and al,
  update on your comment: our open-source implementation 
(http://ecdysis.viagenie.ca) that you are using has been updated to fix 
the CNAME (as well as other) bug. Please try it out and report if you 
are still having issues, specially the one that are not implementation 
specific. (for implementation specific, there is a -discuss list for the 
project).

Regards, Marc.

Le 10-11-15 09:44, [email-masked] a écrit :
> 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
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of ext Cameron Byrne
>> Sent: 10. marraskuuta 2010 16:13
>> To: Mikael Abrahamsson
>> Cc: [email-masked]
>> Subject: Re: [v6ops] NAT64+DNS64
>>
>> On Wed, Nov 10, 2010 at 4:29 AM, Mikael Abrahamsson<[email-masked]>
>> wrote:
>>> On Wed, 10 Nov 2010, Marc Blanchet wrote:
>>>
>>>> - 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.
>>>
>>>> - 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.
>>>
>>> Is this written down somewhere? If not, what WG should handle this?
>>>
>>>> yes, some platforms behave better. some are similar to what you have
>> seen.
>>>
>>> *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).
>>
>>
>> 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
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
=========
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