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

["Teco Boot" <[e-mail]>]

I do not want to suggest a solution at this moment. After Philly, I will.
My intention was to make clear taht it is hard for a MANET node to select a
source address that is appropriate for communication with nodes outside a
multi-homed MANET. And that for a MANET router connected host, it is
undoable. I think try-and-error is not an acceptable solution.
I always thought this is an important real world issue. Your effort on this
is some evidence;-)
Teco.

> -----Oorspronkelijk bericht-----
> Van: Simone Ruffino [mailto:[e-mail]]
> Verzonden: woensdag 20 februari 2008 17:27
> Aan: Teco Boot
> CC: [e-mail]; [e-mail]
> Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed.
> 
> 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