Note: I changed the subject.
>>>>> On Wed, 24 May 2000 10:49:00 -0700 (PDT),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> Interaction with IPV6_PKTINFO still confuses me. I'm unsure about
>> interaction between IPV6_PKTINFO and bind(2) if we use both (it is
>> not documented in 2292bis-01). I'm even more unsure about its
>> interaction with mobile-ip6.
> My assumptions have always been that IPV6_PKTINFO has the same semantics as
> bind() in this respect.
I think you two are actually comparing the semantics of sin6_scope_id
and the semantics of IPV6_PKTINFO, right? Then, I think that those two
are different, at least based on the model described in
draft-ipngwg-scoping-arch-01.txt (or
draft-ietf-ipngwg-scoping-arch-00.txt...01 seems to be officialy
unpublished).
Since links are broader scope than interfaces, IPV6_PKTINFO
(conceptually) imposes stronger restriction than sin6_scope_id.
For example, suppose that two interfaces ne0 and ne1 belong to a same
link (and the link only consists of those two interfaces). Then
consider the following combinations:
1. sin6_scope_id = 1, without IPV6_PKTINFO
(where 1 is the link identifier that contains ne0 and ne1)
2. sin6_scope_id = 0, with IPV6_PKTINFO(ne0)
3. sin6_scope_id = 0, with IPV6_PKTINFO(ne1)
In my understanding, the outgoing interface for each case is as
follows:
1. ne0 or ne1. It would depend on implementation, or the status of
runtime routing table.
2. ne0
3. ne1
>> Another example of confusion: interface selection. We have so many
>> ways to specify outgoing interface, or scope zone, when we throw packet
>> to outside:
>> 1. sin6_scope_id field in sendto(2)/sendmsg(2)
>> 2. sin6_scope_id field in connect(2)
>> 3. sin6_scope_id field in bind(2)
>> 4. IPV6_PKTINFO sticky option
>> 5. IPV6_PKTINFO on sendmsg(2)
>> (3) to (5) specify source, but if we use link-local source they
>> would affect the outgoing interface selection.
To make sure: conceptually, all scoped sources (including site-locals)
would affect the outgoing interface, when the node is multi-zoned.
>> we know (1) overrides (2) in IPv4. other interactions are not defined.
>> FYI, KAME uses the following order (we know this is not in standrd,
>> but this was the best we could come up with):
>> - IPV6_PKTINFO on sendmsg(2) is the strongest
>> - IPV6_PKTINFO on sticky option
>> - address specified by basic API on transmission (one-time option, like
>> sendto)
>> - address put into pcb struct (sticky, like bind/connect) is the weakest
Basically agreed (actually I implemented the above order :-), but I
think we need some additional restrictions. For example,
if a scoped address is specified by bind(2) and the outgoing
interface specified by IPV6_PKTINFO does not belong to the zone
determined by the bound address' sin6_scope_id field, the kernel
should not send the packet and return an error.
However, I'm not sure these additional rules should be noted in
rfc2292bis.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
