Thinking about IPv6 and DEPRECATED addresses

Tsuyoshi MOMOSE t-momose at
Fri Mar 2 00:03:26 UTC 2007

On 2007/02/28, at 20:33, Max Laier wrote:

>> So, I am contemplating adding to rtsock.c the ability to
>> send these types of events up. I am thinking on adding
>> this there for two reasons..
>> a) SCTP already hooks into the routing socket to get
>>     interface changes.
>> and
>> b) It may well be a relevant fact that if an address becomes
>>     DETACHED or non-DETACHED (etc) for a routing process
>>     to want to know about..
>> What do others think? If I am off in the weeds somewhere and
>> this does not concern the routing socket I could use other
>> methods .. including isolating the "look at the state" flags
>> into a special place so that proper locking could be added
>> when we actually do locking for the ifa's... of course I would
>> prefer just not to have to look at it :-D
>> Opinions if this is a good idea or not??
> Great idea.  I'm also CC-ing Tsuyoshi MOMOSE who is working on  
> importing
> MIP6 which will likely be interested in this information (in  
> userland) as
> well.  AFAIK, the mnd already listens on the rtsock to pick up new
> addresses as soon as possible, but not sooner (for which it has to go
> through great lengths).

Thanks for CCed to me.

As Max said, our Mobile IPv6 stack uses rtsock to detect changing  
address address such as added, deleted.
(but actually, the program which listens the rtsock is not mnd but mdd 
(babymdd). The aim of mdd is just detcting the movement of the node  
and notifies to mnd its movement information)

To do that, SHISA introduces a new routing socket message  
RTM_ADDRINFO which is sent from kernel when a new address is  
attached, detached, and DAD was done. So, you can get an address  
information soon as possible.
I guess the message meets Randall's requirement for the SCTP.

I don't start the SHISA porting to the head yet, but I can begin the  
port first from the RTM_ADDRINFO part if you hope.

Tsuyoshi MOMOSE / ももせつよし
momose at (Underconstruction)

More information about the freebsd-net mailing list