RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

[James Guichard <[e-mail]>]

Hi Adrian,

Yes, it is the same argument. In the case that Tom described I was trying to show that of course undesirable things will happen if you send a G-SRH to a node that does not support compression but this should not happen if the policy is updated correctly to remove the downgraded node as it can no longer support the policy requirements. It is true that there is a timing window if you rely solely on the routing convergence. I suppose theoretically it is possible to downgrade the node and reboot it before everyone has had time to converge and remove the nodes compression capability state,  but you would have to be pretty darn nimble to beat the convergence time 8^); besides I would expect that like any maintenance task you would first want to take the node out of any existing policy *before* you downgraded it to not support compression.

Jim



From: Adrian Farrel <[e-mail]>
Sent: Saturday, May 30, 2020 6:37 PM
To: James Guichard <[e-mail]>; 'John Scudder' <[e-mail]>
Cc: 'Bob Hinden' <[e-mail]>; 'IPv6 List' <[e-mail]>
Subject: RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Hi Jim,

Isn’t this the MPLS argument? If you put the wrong label on a packet (at any point in its path) or if you forward it to the wrong next hop, then all bets are off. (Well, actually, there is a pretty good bet – the packet will be misdelivered.)

You are correctly saying that placing an incorrect ‘next hop’ address on a packet will result in it being delivered to the wrong next hop, and the next lookup will give undesired results because the context for the lookup is broken.

This is, of course, a problem with overlays and private address spaces. Just imagine if the wrong VRF identifier was used (in any form of VPN), or if the packet was tunnelled to the wrong PE. But does that stop us from using VPNs? No, it makes us be more careful with how we write the code.

Best,
Adrian

From: ipv6 <[e-mail]<mailto:[e-mail]>> On Behalf Of James Guichard
Sent: 30 May 2020 23:05
To: John Scudder <[e-mail]<mailto:[e-mail]>>
Cc: Bob Hinden <[e-mail]<mailto:[e-mail]>>; IPv6 List <[e-mail]<mailto:[e-mail]>>
Subject: RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Hi John,

Let me try to make what I said clearer as you are right, I was not saying two nodes have the same address.

I was trying to point out that with any source routed solution you quite obviously need to make sure that you send the packets to the right nodes along the path specified by your policy and those nodes must support the functionality that you require for that path. Why? Because if you send a CRH packet to the *wrong* node and that node happens to have an identifier matching the one on the packet received, then it will do a lookup on that identifier and forward to the IP address resolved from the identifier -> IPv6 address mapping and that destination might not be the one you meant to send it to next on the path. Likewise, if you send a packet to the *wrong* node with G-SRH and that node does not support compression then this would be bad as well. Moral of the story I was trying to tell is don’t do that and in fact in practice it will not happen if the policy reflects the intent which in the case Tom was talking about would mean that the original node should no longer be in the policy as the policy should have been updated when the node was lost from the topology.

Jim



From: John Scudder <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, May 30, 2020 4:29 PM
To: James Guichard <[e-mail]<mailto:[e-mail]>>
Cc: Tom Herbert <[e-mail]<mailto:[e-mail]>>; Bob Hinden <[e-mail]<mailto:[e-mail]>>; IPv6 List <[e-mail]<mailto:[e-mail]>>
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Jim,

On May 30, 2020, at 3:46 PM, James Guichard <[e-mail]<mailto:[e-mail]>> wrote:

Further, in normal operation of any source routed solution you will need to make sure that packets end up at the right nodes as nasty things might happen if you don’t - this is actually especially bad with CRH as far as I can tell as if you send a packet to the wrong node and it happens to have a local identifier the same as the incoming packet its going to use that local CRH-FIB entry and send the packet to some IPv6 destination that was not the intended recipient.

I think you’re mistaken, or at least the situation you describe is far more pathological than the one Tom described and you’re dismissing. Consider that in order for what you say to happen, the incoming packet would have to have, as its destination address, an address of the “wrong node”. You can’t just send the packet out the wrong interface and have its CRH identifier misconstrued by any old router that touches it, the DA has to identify the node that receives it.

So now, by definition, you’re saying that two different nodes in the same network have the same (non link-local, also by definition) address. That’s a broken network, of course it’s doing broken things. Alternately, you didn’t mean to say that, and are mistaken about CRH processing.

—John