Re: draft-ietf-v6ops-addr-select-ps-01.txt and draft-ietf-v6ops-addr-select-req-02.txt WGLC

[Arifumi Matsumoto <arifumi@nttv6.net>]

Hi, Zhang.

I guess the e-mail from Jean just before your e-mail to v6ops ML
is the solution for this problem, isn't it ?

IMHO, this SIP address selection issue is application specific,
in that SIP treats IP addresses on its layer. We rather focus on
system-wide address selection problems. I suppose application
specific address selection issues should be treated separately
and individually when it is necessary.

> Should we consider another problem relating to IPv6 address selection in
> this draft?
>
> Think about this scenario in IPv6 network when SIP protocol is used:
>                                   _______________
>                                  |  IPv6 network|________ SIP Server
>                                  |______________|
>                                    /           \
>                                   /             \
>                                  /               \
>                              Router 1        Router 2
>                                 |                 |
>                                 |                 |
>                           SIP Phone tiger      SIP Phone  Deer
>                                 |                 |
>                                 |_________________|
>                                          |
>                                       Router 3
>
> In this situation, SIP Phone Tiger and Deer both have multiple addresses,
> E.g for tiger, both R1 and R3 will assign address to it, and so as sip 
> phone
> Deer.
>
> Considering a sip request message initiated by tiger to sip server,
> according to RFC3484, most likely the IPv6 address assigned by Router 1 
> will
> be used as the source, since the destination is sip server.  And it's
> perfectly fine  for all the signaling message between  tiger/sip server, 
> and
> deer/sip server pairs.
>
> But it's not the case for the media traffic. Obviously, for both tiger and
> deer, the addresses assigned by R3 should be used for media traffic since
> they belong to the same subnet. So the problem is, should tiger's SDP
> message carry all the IPv6 addresses it has to deer so that deer can make
> the right decision; or, should a mechanism be used between tiger and 
> deer to
> exchange the address selection information for SDP message?
>
> RFC3266(IPv6 support of SDP) doesn't address this. So I am not sure whether
> this problem should be addressed in this draft or another. Or have we
> already had a solution?
>
> 2007/6/21, Fred Baker <fred@cisco.com>:
> > This is to initiate a two week working group last call of draft-ietf-
> > v6ops-addr-select-ps-01.txt and draft-ietf-v6ops-addr-select-
> > req-02.txt. Please read these now. If you find nits (spelling errors,
> > minor suggested wording changes, etc), comment to the authors; if you
> > find greater issues, such as disagreeing with a statement or finding
> > additional issues that need to be addressed, please post your
> > comments to the list.
> >
> > We are looking specifically for comments on the importance of the
> > documents as well as its content. If you have read the documents and
> > believe them to be of operational utility, that is also an important
> > comment to make. If you have read them and think they miss an
> > important consideration, that is very important.
> > <?xml version="1.0" encoding="UTF-8"?>


--
Arifumi Matsumoto
   IP Technology Expert Team
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: arifumi@nttv6.net