Subject: Comments on addr-select-sol

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 24 Jul 2007 19:03:29 +0300

Hello,

Been reviewing the draft, and I am a bit puzzled as to why the 
implementability and compatibility with RFC3493 falls in the "other issues" 
category.

Most IPv6-enabled applications are currently relying on getaddrinfo then 
connect/sendto APIs, or variants thereof. getaddrinfo() queries DNS or 
whatever, and gives an ordered list of possible destination address, then 
connect() or sendto() decide which source address to use to reach a given 
destination. It might be worth noting that sendto() is non-blocking, so 
essentially any exchange with the network has to be done in getaddrinfo().

Now, that still leaves a lot of room for doing lots of fancy and advanced 
stuff in getaddrinfo(), along the DNS query. But I think it is worth looking 
deeper at. I do think we should avoid deprecating RFC3493 unless there is 
really a very very compelling reason to do so.

I am a bit suspicious as to whether the "trial-and-error" approach can 
actually work with these considerations in mind.

-- 
Rémi Denis-Courmont

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 01:15:50 +0900 (JST)

> really a very very compelling reason to do so.

	if you are suggesting changes to getaddrinfo(3) API, no.  you can't.
	more than 5 years late.  especially if you are suggesting getaddrinfo(3)
	to return source addresses.

itojun

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 24 Jul 2007 19:33:43 +0300

On Tuesday 24 July 2007 19:15:50 Jun-ichiro itojun Hagino wrote:
> > stuff in getaddrinfo(), along the DNS query. But I think it is worth
> > looking deeper at. I do think we should avoid deprecating RFC3493 unless
> > there is really a very very compelling reason to do so.
>

Agreed. That was pretty much my point.

-- 
Rémi Denis-Courmont

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Jul 2007 13:34:43 +0900

Thank you for your comment.
This is the 1st comment I received on list for this draft :)

> really a very very compelling reason to do so.

Good point.
I had no idea how to set-up a requirement item that covers "other 
issues". "compability with RFC3493" looks like a good requirement item.

> actually work with these considerations in mind.

IMO, trial-and-error approach can work with RFC3493.
You may suppose that the kernel changes the source address of the
existing connections, but it doesn't. The kernel just stores cache
for successful/unworkable address selection and utilize it for the
next address selection.

Rather, I am suspicious about "question-and-answer" approach about
this point. How can we implement that in getaddrinfo() without
changing the APIs ?

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 25 Jul 2007 21:53:02 +0300

> this point. How can we implement that in getaddrinfo() without

Indeed, if an application does:

getaddrinfo("2001:db8::1", "53", { 0, SOCK_DGRAM, 0, AI_NUMERICHOST }, ...)
socket()
connect()

none of the function calls are allowed to block (UDP connect() cannot block, 
numeric getaddrinfo() cannot block), so you cannot ask anything from the 
network. So it is indeed doubtful whether the Q&A approach works. In fact, I 
suspect only the RFC3484-ish approach can work at all.

As such, I'd much rather go for the approach put forward by Brian Carpenter, 
which if I understand correctly, consists of extending RFC3484 so you can 
deliver the policy tables at network configuration time.

I might be wrong. But I think any approach will need to be prototyped before 
it's selected.

-- 
Rémi Denis-Courmont