Subject: [Roll] [roll] #56: Transit and Target address mismatch

From: "roll issue tracker" <[email-masked]>
Date: Tue, 06 Jul 2010 11:41:09 -0000

#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/>

---

From: "roll issue tracker" <[email-masked]>
Date: Thu, 22 Jul 2010 19:18:21 -0000

#56: [Roll] Transit and Target address mismatch
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:  wintert@…      
     Type:  enhancement      |       Status:  closed         
 Priority:  minor            |    Milestone:                 
Component:  rpl              |      Version:                 
 Severity:  In WG Last Call  |   Resolution:  fixed          
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Here is the new text that will be incorporated to rev-11 of RPL, which
 allows us to close this ticket:

 --------------------------------------------

  -  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.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Type = 8    | Option Length | Prefix Length
 |L|A|R|Reserved1|

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Valid Lifetime
 |

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Preferred Lifetime
 |

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           Reserved2
 |

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |
 |
        +
 +
        |
 |
        +                            Prefix
 +
        |
 |
        +
 +
        |
 |

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 23: Format of the Prefix Information Option

    The Prefix Information option may be used to distribute the prefix
 in
    use inside the DODAG, e.g. for address autoconfiguration.

    ....

    R     1-bit Router address flag.  When set, indicates that the
 Prefix
          field contains a complete IPv6 address assigned to the sending
          router that can be used as parent in a target option.  The
          indicated prefix is the first Prefix Length bits of the Prefix
          field.  The router IPv6 address has the same scope and
 conforms
          to the same lifetime values as the advertised prefix.  This
 use
          of the Prefix field is compatible with its use in advertising
          the prefix itself, since Prefix Advertisement uses only the
          leading bits.  Interpretation of this flag bit is thus
          independent of the processing required for the On-Link (L) and
          Autonomous Address-Configuration (A) flag bits.

 - 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 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.

 Transit Information is updated as follows:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Type = 6    | Option Length |E|  Reserved   | Path Control
 |

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Path Sequence | Path Lifetime |
 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
        |
 |
        +
 +
        |
 |
        +                        Parent Address*
 +
        |
 |
        +
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The '*' denotes that the Parent Address is not always present, as
    described below.

             Figure XX: Format of the Transit Information option

    ....

    External (E):  1-bit flag.  The 'E' flag is set to indicate that the
          parent router redistributes external targets into the RPL
          network.  An external target is a target that has been learned
          through an alternate protocol.  The external targets are
 listed
          in the target options that immediately precede the Transit
          Information option.  An external target is not expected to
          support RPL messages and options.

    ....

 DAO rules are updated as follows:

    In non-storing mode additional rules apply to ensure the continuity
    of end-to-end source route path:

    1.  The address used as transit parent by the children MUST be taken
        from a PIO with the 'R' flag set from that parent but is not
        necessarily on link for the children.

    2.  The router that advertises an address as parent in a PIO MUST
        also advertise that address as target in a DAO message.

    3.  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.

    4.  A router might have targets that are not known to be onlink for
 a
        parent, either because they are addresses located on an
 alternate
        interface or because they belong to nodes that are external to
        RPL, for instance connected hosts.  In order to inject such a
        target in the RPL network, the router MUST advertise itself as
        the Parent Address in the Transit Information option for that
        target, using an address that is onlink for that nodes DAO
        parent.  If the target belongs to an external node then the
        router MUST set the External 'E' flag in the transit
 information.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/56#comment:1>
roll <http://tools.ietf.org/wg/roll/>