Subject: which interface to choose to send to destination link-local address - any RFC?

From: Parav Pandit <[email-masked]>
Date: Wed, 14 Apr 2010 02:00:36 -0700 (PDT)

Hi,

In IPv6 stack implementation,

How IPv6 stack should select the outgoing interface to choose (when multiple interfaces) are available? Typically when the destination is the link-local address which may be on-link on both the interfaces (before the neighbor discovery) is done?

Should IPv6 stack do Neighbor discovery on all multiple interfaces in the host?

Which RFC defines this behavior? I referred RFC 3484 (Default Address Selection for IPv6) but doesn't seem to define this.

I hope I am asking on the right mailing list. If not please divert me to the correct one.

Regards,
Parav Pandit

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 14 Apr 2010 11:29:59 +0200

On Wed, 14 Apr 2010 02:00:36 -0700 (PDT), Parav Pandit
<[email-masked]> wrote:
> How IPv6 stack should select the outgoing interface to choose (when
> multiple interfaces) are available? Typically when the destination is the
> link-local address which may be on-link on both the interfaces (before
the
> neighbor discovery) is done?

Typical IPv6 stacks will simply rely on the application to provide the
interface (as sockaddr_in6.sin6_scope_id). If the interface is not
provided, attempt to send to a link-scoped destination will simply fail.

> Should IPv6 stack do Neighbor discovery on all multiple interfaces in the

No.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 14 Apr 2010 11:31:36 +0200 (CEST)

On Wed, 14 Apr 2010, Parav Pandit wrote:

> How IPv6 stack should select the outgoing interface to choose (when multiple interfaces) are available?
> Typically when the destination is the link-local address which may be on-link on both the interfaces (before
> the neighbor discovery) is done?
> 

The application should know which interface/link to choose in case of 
link-local address. The link-local is relevant to a specific link only.

e.g.

ping6 -I bge0 fe80::21b:63ff:fe9f:4527
PING6(56=40+8+8 bytes) fe80::206:5bff:fef2:41c1%bge0 --> 
fe80::21b:63ff:fe9f:4527
16 bytes from fe80::21b:63ff:fe9f:4527%bge0, icmp_seq=0 hlim=64 time=7.292 
ms
16 bytes from fe80::21b:63ff:fe9f:4527%bge0, icmp_seq=1 hlim=64 time=0.656 
ms
^C
--- fe80::21b:63ff:fe9f:4527 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.656/3.974/7.292/3.318 ms

ping6 fe80::21b:63ff:fe9f:4527
ping6: UDP connect: Network is unreachable

If the application knows which link to use then IPv6 protocol stack might 
use ND to dicover/reach the node.

Best Regards,
 		Janos Mohacsi

---

From: Parav Pandit <[email-masked]>
Date: Wed, 14 Apr 2010 03:56:49 -0700 (PDT)

Thanks for the quick help.
Good example of UDP.
So in case of TCP, client which tries to connect to the server, should provide its link-local source address during socket(), bind() calls. Based on that IPv6 stack will figure out the out-going interface.
Is that correct understanding?

Regards,
Parav Pandit

--- On Wed, 4/14/10, Mohacsi Janos <[email-masked]> wrote:

From: Mohacsi Janos <[email-masked]>
Subject: Re: which interface to choose to send to destination link-local address - any RFC?
To: "Parav Pandit" <[email-masked]>
Cc: [email-masked]
Date: Wednesday, April 14, 2010, 3:01 PM

> I hope I am asking on the right mailing list. If not please divert me to the correct one.

The application should know which interface/link to choose in case of link-local address. The link-local is relevant to a specific link only.

e.g.

ping6 -I bge0 fe80::21b:63ff:fe9f:4527
PING6(56=40+8+8 bytes) fe80::206:5bff:fef2:41c1%bge0 --> fe80::21b:63ff:fe9f:4527
16 bytes from fe80::21b:63ff:fe9f:4527%bge0, icmp_seq=0 hlim=64 time=7.292 ms
16 bytes from fe80::21b:63ff:fe9f:4527%bge0, icmp_seq=1 hlim=64 time=0.656 ms
^C
--- fe80::21b:63ff:fe9f:4527 ping6 statistics ---

If the application knows which link to use then IPv6 protocol stack might use ND to dicover/reach the node.

Best Regards,
        Janos Mohacsi

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Apr 2010 07:58:05 -0400

On 2010-04-14 06:56, Parav Pandit wrote:
> So in case of TCP, client which tries to connect to the server, should
> provide its link-local source address during socket(), bind() calls.

No. On the client side there should be no bind() call, and the socket() 
call is unaffected since it doesn't take any address parameter. In the 
connect() call, for the struct sockaddr parameter, the sin6_addr member 
will contain the server's link-local address and the sin6_scope_id 
member will contain the scope id of the client's interface on which the 
server can be reached.

> Based on that IPv6 stack will figure out the out-going interface.

There is no need for the stack to "figure out" the outgoing interface 
since the application tells it plainly in the sin6_scope_id parameter.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Apr 2010 09:39:25 +1200

I think this topic belongs to the MIF WG. Maybe they have
already discussed it. If not, they probably should.

http://datatracker.ietf.org/wg/mif/charter/

   Brian

On 2010-04-14 21:00, Parav Pandit wrote:
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 22 Apr 2010 14:02:13 -0700

At Wed, 14 Apr 2010 07:58:05 -0400,

> member will contain the scope id of the client's interface on which the 

And, if the implementation supports an extension to textual address
representation as described in RFC4007 Section 11, and if the
application uses the getaddrinfo(3) library function that understands
the extension, the application doesn't have to do anything about
sin6_scope_id.

I don't know how many implementations support this extension, but all
BSD variants should support it, and Linux (i.e. glibc getaddrinfo)
seems to support it.  I heard Windows also support the extension, but
I don't know much about it.

BTW: to be pedantic as a co-author of RFC4007, I'd like to note that
"link" is a broader scope than "interface", at least architecturally.
So, for example, two different interfaces can belong to the same
single link, and "the sin6_scope_id member will contain the scope id
of the client's interface on which the server can be reached." should
actually read "...client's link on which ...".  In practice, however,
many (if not all) implementations assume one-to-one mapping between
links and interfaces, so we can normally use "interface" and "link"
interchangeably.

> since the application tells it plainly in the sin6_scope_id parameter.

That's true, although I've heard there used to be an implementation
that tries neighbor discovery on all possible links when the outgoing
link is ambiguous from the destination address.

I'd also like to note that RFC4007 suggests the implementation have
the notion of "default scope zone".  In some sense, it could be
considered a way for the stack to figure out outgoing link (interface)
when it's ambiguous.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.