Re: [Autoconf] AUTOCONF Problem Statement: reviews needed.

["Simone Ruffino" <[e-mail]>]

Teco,

Teco Boot wrote:
> Hi Carlos,
> Maybe it is true that is some "unmanaged and open" wired networks, the
> multi-homing issue can arise. But I think the hosts can deal with this
> issue, by selecting a default gateway. And yes, there is a relation between
> the selected gateway and the generated SLAAC address.
> I think that in a open, wireless network where we introduce a MANET
> protocol, the problem is out-of-control. The MANET Router connected hosts do
> not have any idea of the MANET topology and I do not see a method that these
> nodes can select a source address, other than try and error.
> The MANET Router itself could perform an internal MANET topology table
> lookup and try to detect the egress to the Internet, and use corresponding
> source address. I think this method does not work in all cases, e.g. session
> continuity during movement is a problem.

:D

FYI, we have implemented (and documented in a expired draft) a solution 
that exactly does that.
And, it is integrated with Mobile IPv6.
I've experimented many times that choosing the wrong border router 
(e.g., picking the first one that MNR hears) can tear a voice call down 
when MANET topology changes. Instead, with the mechanism you're 
suggesting, the best possible performance is guaranteed.

Only problem: solution was designed for a multi-link subnet MANET model, 
but I think the underlying principle (ruoting table lookup to find best 
source address) is still sound.


> Any other opinions?
> Teco.
> 
> 
>> -----Oorspronkelijk bericht-----
>> Van: Carlos Jesús Bernardos Cano [mailto:[e-mail]]
>> Verzonden: woensdag 20 februari 2008 16:54
>> Aan: Simone Ruffino
>> CC: Teco Boot; [e-mail]
>> Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed.
>>
>> Hi Somone, all.
>>
>> 	Two short comments below.
>>
>> On mié, 2008-02-20 at 15:01 +0100, Simone Ruffino wrote:
>>> Hi Teco,
>>> some comments below.
>>>
>>> Thanks for your comments and regs,
>>> Simone
>>>
>>> Teco Boot wrote:
>>>> Hi,
>>>>
>>>> Some comments inline.
>>>>
>>>> I have more thoughts which I did not mention in my first response:
>>>>
>>>> On uniqueness validation, I posted before my reservations on active
>>> DAD. In
>>>> many cases, this is not needed. RFC4862:
>>>>>  To accommodate
>>>>>  sites that believe the overhead of performing Duplicate Address
>>>>> Detection outweighs its benefits, the use of Duplicate Address
>>>>> Detection can be disabled through the administrative setting of a
>>>>> per-interface configuration flag.
>>>> The old version of our Problem Statement had some text on this.
>>>>
>>>> On multi-homed subordinate MANETs, the current document does not
>>> describe
>>>> this scenario in detail. It is just an instance of a subordinate
>>> MANET, as
>>>> this category is described with "is connected to at least one
>>> external
>>>> network N".
>>>> I think multi-homed subordinate MANET scenario introduces a large,
>>> new
>>>> problem which is related to the selection mechanism of the path to
>>> one of
>>>> the external networks. This path selection is out-of-control for
>>> Autoconf,
>>>> as it is up to the (MANET) routing protocol to find out the path to
>>> the
>>>> destination.
>>>> Scenario:
>>>>
>>>>
>>>>                    '.                           /
>>>>                     `.        Network N        /   Topologically
>>> correct
>>>>                       `.                    _,'          prefix q::
>>> with
>>>>   Topologically correct `-.__           _,,'        respect to
>>> network M
>>>>         prefix p:: with      `'-.,._,,''                    ___
>>>>    respect to network N          :                       ,-´
>>>>                                +-:-+                    /
>>>>                                |MNR|                   ;    N
>>>>                                +-|-+                  /     E
>>>>               +-+  +---+ /      /|\       \ +---+     ;     T
>>>>               | |...MNR---       .-.      ---MNR:.....,     W
>>>>               +-+  +---+ \    ,-(  _)-.   / +---+     !     O
>>>>                            .-(_ MANET  )-.            !     R
>>>>               Other       ( Communication )           :     K
>>>>               Nodes          `-(______)-'              \
>>>>               and         \|/             \|/           :   M
>>>>               Networks   +-|-+           +-|-+          \
>>>>                          |MNR|    \|/    |MNR|           \_____
>>>>                          +-:-+   +-|-+   +-:-+
>>>>                                  |MNR|     :
>>>>                                  +-:-+    +-+
>>>>                                           +-+
>>>>
>>>> Now, we have to select a topologically correct prefix p:: with
>>> respect to
>>>> network N but not to network M or a topologically correct prefix
>> q::
>>> with
>>>> respect to network M but not to network N. It is very hard to
>> select
>>> p:: or
>>>> q::, as it is dependent on the (dynamic) topology of the MANET and
>>> the MANET
>>>> routing protocol.
>>> Great that you raised this point, because I've always stressed this
>> is
>>> a a problem :).
>>>
>>> I agree: the selection of prefix (and addresses) to use for
>>> application sessions with external hosts is hard, because it directly
>>> impacts on the path followed by return traffic *from* the external
>>> network *to* MNRs
>>> *in* the MANET. Routing protocols can only affect the other
>> direction,
>>> i.e. from the MNR to the external network.
>>>
>>> However, let me elaborate more on this.
>>> I think selection of either p:: or q:: is not really a problem per-
>> se.
>>> In fact, MNRs (and connected hosts) could configure both p:: and q::
>>> on
>>> their interfaces: IPv6 permits it. And hosts connected to MNRs could
>>> initiate application sessions with hosts in both networks M and N:
>>> source address selection rules will choose the prefix with the right
>>> scope.
>>>
>>> Moreover, if both Network M and N are eventually connected to the
>>> Internet and if hosts (attached to MNRs) want to initiate application
>>> sessions with hosts on the Internet, p:: and q:: could be equivalent.
>>>
>>> But in this case, the choice of prefix could depend on other factors,
>>> e.g. performance. In fact, it is actually more important to choose
>> the
>>> optimal Border MNR, in order to prevent return traffic to traverse
>>> long paths in the MANET. Choosing a very far away border router (in
>>> terms of number of hops, w.r.t. the MNR initiating the session) has a
>>> direct impact on applications, especially jitter-sensitive ones like
>>> VoIP.
>>>
>>> So in my opinion there is a 1:1 correspondence between performance
>> and
>>> prefix choice.
>> [Carlos] I think this problem/scenario also happens in non-MANET
>> scenarios (it's a multihoming issue) and it is not particular of IP
>> address autoconfiguration. I agree is a very interesting issue, but I'm
>> not sure the IP autoconf PS is the right place. The only specific issue
>> I see there is how to detect that an initially multihomed subordinate
>> MANET gets disconnected from one of the external networks it was
>> attached to, and even in this case, this also occurs in non-MANETs.
>>
>>> By my knowledge, the MANET protocols we have right now are
>>>> using the destination IP address for forwarding and not the source
>>> IP
>>>> address.
>>>> Any thoughts including this problem in the Problem Statement
>>> document?
>>> I think it could be useful to add some considerations, but, we
>> decided
>>> to keep this version of PS "to-the-bone" as much as possible and get
>>> agreement on this. I'd like to hear opinion of other authors as well.
>> [Carlos] Again, I don't see this as an IP address autoconfiguration
>> issue. This is related to MANET routing protocols, and therefore I'd
>> prefer not to include any consideration in the PS.
>>
>> 	Regards,
>>
>> 	Carlos
>>>> I have also my thoughts on needs for authorization on using the
>>> external
>>>> network. I think in real world, many access providers no not allow
>>>> unauthorized nodes to have access. Getting an address in not that
>>> much a
>>>> problem, using the access network is.
>>>>
>>>> Regards, Teco
>>>>
>>> --------------------------------------------------------------------
>>>
>>> CONFIDENTIALITY NOTICE
>>>
>>> This message and its attachments are addressed solely to the persons
>>> above and may contain confidential information. If you have received
>>> the message in error, be informed that any use of the content hereof
>>> is prohibited. Please return it immediately to the sender and delete
>>> the message. Should you have any questions, please contact us by
>>> replying to [e-mail].
>>>
>>>         Thank you
>>>
>>>                                         www.telecomitalia.it
>>>
>>> --------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Autoconf mailing list
>>> [e-mail]
>>> http://www.ietf.org/mailman/listinfo/autoconf
>> --
>> ¡ASÓCIATE! Gratis para estudiantes  http://www.telematica.ws
>>  Carlos Jesús Bernardos Cano     http://www.netcoms.net
>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   WEEDEV 2008: 1st Workshop on Experimental Evaluation and
>>         Deployment Experiences on Vehicular networks
>>                   http://www.weedev.org/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/autoconf
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [e-mail].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------
                        
_______________________________________________
Autoconf mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/autoconf