Subject: Re: [Roll] Transit and Target address mismatch

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 Jul 2010 14:55:39 +0200

Hi Mathilde:

Yes we can improve the text : )

Yes, all the RH are based on global addresses. I tend to think that the non-storing mode should even use global addresses as source / destination for DAO/DAO_ACK so nodes talk directly to the root as opposed to sending DAOs hop by hop.

And no, global addresses are not off link.  They are not expected to be all onlink for the purpose of ND lookup, but some may be. And this text expects that those used for RH are effectively onlink to enforce a strict source routing. So a node should be able to NS those addresses to assert continuous connectivity.

One even more tricky thing is the use of IP in IP that seems to be generalized now as soon as we insert a RH or a HbH option. I think that the resolution of your issue should also clearly state what are the tunnel endpoints, in particular when the destination on the RPL side is a dumb host. RPL should be able to differentiate the last router from the target.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 1:17 PM
To: ROLL WG
Subject: [Roll] Transit and Target address mismatch

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

 

Durvy Mathilde
Software Engineer
Technology center

[email-masked] <mailto:[email-masked]> 
Phone: +41 21 822 1725
Mobile: +41 76 396 8116

Cisco Systems International Sàrl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home page <http://www.cisco.com> 

 Think before you print.

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.

---

From: Daniel Gavelle <[email-masked]>
Date: Tue, 06 Jul 2010 14:05:20 +0100

I like the idea of sending a DAO directly from the node to the root in a 
non storing network.  This avoids the DAO travelling up the tree a hop 
at a time with an ack for each hop.  We wouldn't need a type 4 routing 
header in the packet as the direction of travel is up the DAG.

The global IP address of the root would need to be distributed in the 
DIS if DAO's' could travel directly to the root in this way.  Currently, 
the DODAG ID does not have to be the IP address of the root but can be 
any unique identifier.  We could either define the DODAG ID to be the IP 
address of the root or add another field / option to the DIS with the 
global IP address of the root.

Daniel.

Pascal Thubert (pthubert) wrote:
> Yes, all the RH are based on global addresses. I tend to think that the 
> non-storing mode should even use global addresses as source / 
> destination for DAO/DAO_ACK so nodes talk directly to the root as 
> opposed to sending DAOs hop by hop.
> 
>  
> 
> And no, global addresses are not off link.  They are not expected to be 
> all onlink for the purpose of ND lookup, but some may be. And this text 
> expects that those used for RH are effectively onlink to enforce a 
> strict source routing. So a node should be able to NS those addresses to 
> assert continuous connectivity.
> 
>  
> 
> One even more tricky thing is the use of IP in IP that seems to be 
> generalized now as soon as we insert a RH or a HbH option. I think that 
> the resolution of your issue should also clearly state what are the 
> tunnel endpoints, in particular when the destination on the RPL side is 
> a dumb host. RPL should be able to differentiate the last router from 
> the target.
> 
>  
> 
> Cheers,
> 
>  
> 
> Pascal
> 
>  
> 
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Mathilde Durvy (mdurvy)
> *Sent:* Tuesday, July 06, 2010 1:17 PM
> *To:* ROLL WG
> *Subject:* [Roll] Transit and Target address mismatch
> 
>  
> 
> 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…
> 
>  
> 
> http://www.cisco.com/swa/i/logo.gif
> 
> *Durvy Mathilde*
> *Software Engineer*
> *Technology center
> *
> Phone: *+41 21 822 1725*
> Mobile: *+41 76 396 8116*
> 
> 	
> 
> *Cisco Systems International Sàrl*
> Av. des Uttins, 5
> CH-1180 Rolle
> 
> Think before you print.Think before you print.
> 
> This e-mail may contain confidential and privileged material for the 
> sole use of the intended recipient. Any review, use, distribution or 
> disclosure by others is strictly prohibited. If you are not the intended 
> recipient (or authorized to receive for the recipient), please contact 
> the sender by reply e-mail and delete all copies of this message.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 9 Jul 2010 14:36:25 +0200

Hi Pascal,

Thanks for your answer.

So based on your comments here is my understanding of the current specs.
Please correct me if I’m wrong.

In the non-storing example below we would have:

- A sends DAO with “target Ag, Ap, transit Bg”

- B sends DAO with “target Bg, transit R” together with the information from
A, i.e. “target Ag, Ap, transit Bg”

The address Bg is on-link, although it is formed on a prefix that is
advertised as not on-link.

This is possible thanks to a flag in the PIO sent by B that tells A the PIO
prefix is also an address (in this case Bg) that has to be considered
on-link. Now, my last question would be, how does R knows that Bg is on-link
(when source routing to A)? 

I really think that this should be clarified in the specs. In particular, it
seems that for the DAO part to work:

- Nodes must use the PIO sent by their parents

-- to configure their own global IPv6 address

-- Install a prefix that is not on-link

-- Install the global IPv6 address of their parent as on-link. In
particular, this means the PIO has to be included in the DIO for a node to
adopt a parent as DAO parent. 

- Nodes must use their global on-link IPv6 address as target in DAO

- Nodes must use the global IPv6 address of their parent as transit parent
address.

Is my understanding correct, does everybody agree on that?

Best,

Mathilde

From: Pascal Thubert (pthubert) 
Sent: mardi, 6. juillet 2010 14:56
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: RE: [Roll] Transit and Target address mismatch

Hi Mathilde:

Yes, all the RH are based on global addresses. I tend to think that the
non-storing mode should even use global addresses as source / destination
for DAO/DAO_ACK so nodes talk directly to the root as opposed to sending
DAOs hop by hop.

And no, global addresses are not off link.  They are not expected to be all
onlink for the purpose of ND lookup, but some may be. And this text expects
that those used for RH are effectively onlink to enforce a strict source
routing. So a node should be able to NS those addresses to assert continuous
connectivity.

One even more tricky thing is the use of IP in IP that seems to be
generalized now as soon as we insert a RH or a HbH option. I think that the
resolution of your issue should also clearly state what are the tunnel
endpoints, in particular when the destination on the RPL side is a dumb
host. RPL should be able to differentiate the last router from the target.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 1:17 PM
To: ROLL WG
Subject: [Roll] Transit and Target address mismatch

Hi All,

In this example we have:

- 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

Durvy Mathilde
Software Engineer
Technology center

 <mailto:[email-masked]> [email-masked]
Phone: +41 21 822 1725
Mobile: +41 76 396 8116

 <http://www.cisco.com> Cisco home page

This e-mail may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
e-mail and delete all copies of this message.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Jul 2010 15:51:12 +0200

Hi Mathilde

So based on your comments here is my understanding of the current specs. Please correct me if I'm wrong.

- A sends DAO with "target Ag, Ap, transit Bg"

- B sends DAO with "target Bg, transit R" together with the information from A, i.e. "target Ag, Ap, transit Bg"

[Pascal] The "together with" above is not to be taken too  strictly. B could pack the 2 messages together with -10 though it it not required at all,  and if we go for end to end DAO for non-storing then they are definitively 2 different messages, one from A to root and the other from B to root, with source routed end to end acks.

The address Bg is on-link, although it is formed on a prefix that is advertised as not on-link.

[Pascal] Yes

This is possible thanks to a flag in the PIO sent by B that tells A the PIO prefix is also an address (in this case Bg) that has to be considered on-link.

[Pascal] That is the R bit in 3775 that we are missing as Navneet pointed out. Will be fixed in -11

Now, my last question would be, how does R knows that Bg is on-link (when source routing to A)? 

[Pascal] I think that the clarification to that belongs to the RH spec, not the RPL spec.

I spent quite some time in the RRH spec explaining which address must be visible in a multihomed router.

https://datatracker.ietf.org/doc/draft-thubert-6man-reverse-routing-header/ 

In very short, what's really needed is that the next hop when forwarding a packet is on link for the sender. So Bg should be onlink on the R to Bg link, and Ag should be onling on a B to A link, B's address being anything. R should be able to resolve and NUD Bg, B should be able to resolve and NUDAg, etc...

I really think that this should be clarified in the specs. In particular, it seems that for the DAO part to work:

-- Install the global IPv6 address of their parent as on-link. In particular, this means the PIO has to be included in the DIO for a node to adopt a parent as DAO parent. 

[Pascal] I did not explain that well enough it appears. The child address is onlink on the link where the PIO was received, so that the parent can forward the RH packets to the child. The parent (PIO) address is also onlink in the classical RPL case where the routers have a single interface, but not in the general multihoming case, because that address is oriented towards a parent.

[Pascal] True, and they can have other addresses on other interfaces, a hosts attached. For all those leaf addresses, the router should advertise a DAO with self as parent and those other addresses as targets. We're missing this additional bit that indicates those leaves address that are behind the router, for which the router terminates a tunnel.

- Nodes must use the global IPv6 address of their parent as transit parent address.

[Pascal] Yes. Then again, there can be multihomed routers, with interfaces up (towards the root)and down, and a different address on each. In the multihomed case, the node may have multiple links to multiple parents and children, and thus form multiple addresses for all those links, eventually from a same prefix. The address placed in the PIO(s) is/are on links towards a parent. The transit/target pairs must match so that the address advertised as target must be installed on the link from which the PIO advertised as parent was received...

So I think that the text must indicate that:

-          A router forms a global addresses from the prefix in a parent PIO:

o   assigns that address on the link from that parent so it is onlink there

o   advertises in a DAO that address as target with the address from the PIO as parent in the transit info

-          Once this is done, the node can advertise that same address in its own DIO as a PIO, regardless on whether the address is onlink for the children

[Pascal] Would you agree with might limited rewording above?

Cheers,

Pascal

Best,

Mathilde

Hi Mathilde:

Cheers,

Pascal

Hi All,

In this example we have:

Thanks,

Mathilde

 

Durvy Mathilde
Software Engineer
Technology center

 

 Think before you print.