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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 16 Jul 2010 18:19:36 +0200

To make some room for new flags I'm proposing to reduce the transit lifetime to 3 octets.
This leaves about 200 days before you have to refresh a route.
Would there be an issue with that?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Pascal Thubert (pthubert)
> Sent: Tuesday, July 13, 2010 1:53 PM
> To: Mathilde Durvy (mdurvy)
> Cc: [email-masked]
> Subject: [Roll] Closing issue#56 (2nd): Transit and Target address mismatch
> 
> 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
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Alexander, Roger" <[email-masked]>
Date: Mon, 19 Jul 2010 18:07:57 -0400

+1. 

Roger

> Sent: Friday, July 16, 2010 12:20 PM
> To: [email-masked]
> Subject: Re: [Roll] Closing issue#56 (2nd): Transit and Target
> addressmismatch
> 
> Of
> advertise
> or
> that is behind a