Subject: [Roll] Closing issue#56 (2nd): Transit and Target address mismatch

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Jul 2010 13:53:05 +0200

Rewording after the thread with Mathilde, here's what the resolution for Issue 56 would say:

- The R bit in PIO is used  as in RFC3775 to indicate a (global/ULA) address as opposed to a prefix. 
- The prefix is still valid for the purpose of autoconf when the R bit is set.
- The address used as transit parent by the children MUST be taken from a PIO from that parent but is not necessarily on link for the children.
- The router that it advertises an address as parent in PIO must also advertise that address as target in a DAO for the route recursion to complete.
- An address that is advertised as target in a DAO must be collocated or reachable onlink by the parent that is indicated in the associated transit information.
- A new flag in the transit information qualifies a target address that is behind a router, either as an attached host or installed on another interface. The router is the tunnel endpoint for such address.

We'll note that if the non-storing mode DAO is sent straight to the root then the parent does not have a way to know about the child until a RH pops up. So the bidirectional reachability will be checked at that time.

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: Friday, July 09, 2010 4:58 PM
> To: Mathilde Durvy (mdurvy)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Closing issue#56: Transit and Target address mismatch
> 
> Hi Mathilde:
> 
> Based on the thread we have had I think that the text must clarify that:
> 
> - The R bit in PIO is used  as in RFC3775 to indicate a (global/ULA) address as
> opposed to a prefix.
> - The prefix is still valid for the purpose of autoconf when the R bit is set.
> - The address in the PIO can be used as transit parent by the children but is not
> necessarily on link for the children.
> - The router that it advertises an address as parent in PIO must also advertise
> that address as target in a DAO for the route recursion to complete.
> - An address that is advertised as target in a DAO must be collocated or
> reachable onlink by the parent that is indicated in the associated transit
> information.
> - A new flag in the transit information qualifies a target address that is behind a
> router, either as an attached host or installed on another interface. The router
> is the tunnel endpoint for such address.
> 
> Will that be enough to close 56?
> 
> Pascal
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of roll issue tracker
> > Sent: Tuesday, July 06, 2010 1:41 PM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: [Roll] [roll] #56: Transit and Target address mismatch
> >
> > #56: [Roll] Transit and Target address mismatch
> > -----------------------------+----------------------------------------
> > -----------------------------+--
> > -----------------------------+----
> >  Reporter:  jpv@…            |       Owner:  wintert@…
> >      Type:  enhancement      |      Status:  new
> >  Priority:  minor            |   Milestone:
> > Component:  rpl              |     Version:
> >  Severity:  In WG Last Call  |    Keywords:
> > -----------------------------+----------------------------------------
> > -----------------------------+--
> > -----------------------------+----
> >  Hi All,
> >
> >  Let’s consider the storing mode in a simple topology AàBàR (à mark
> > the parent relationship). Let’s also assume that A has a prefix ‘Ap’
> > and a  global address ‘Ag’ to advertise.
> >  In this example we have:
> >  - A sends DAO with “target Ag, Ap, transit B”
> >  - B sends DAO with “target Bg, transit R” together with the
> > information  from A, i.e. “target Ag, Ap, transit B”
> >
> >  Then R recombines the information to get the route to for example Ap
> > (Target Ap, transit B, target Bg, transit R)  For this to work,
> > transit B and target Bg need to be matched. How can this  be done?
> > Does it mean that the transit parent address has to be a global
> > address? This would imply that we use global addresses in the routing
> header. However 6man-rpl-routing-header says:
> >  “When processing the Type 4 Routing header, a router MUST drop the
> > packet if the next entry is not on-link”
> >  As global addresses have to be off-link in NBMA network like
> > 802.15.4, I  see a problem…
> >
> >  Can you please clarify how addresses are supposed to be used in this
> > source- routing scenario.
> >
> >  Thanks,
> >  Mathilde
> >
> > --
> > Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/56>
> > roll <http://tools.ietf.org/wg/roll/>
> >
> > _______________________________________________
> > Roll mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/roll