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

On Sat, May 30, 2020 at 3:38 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
>
> 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.)

Adrian,

It's not the same thing. For MPLS the equivalent would be more like
sending 16 bit labels instead of 32 bits. As long as all possible
receivers understand that labels or 16 bits it will work. Conceptually
the technique could be applied to any protocol field in any protocol.
For instance, IPv6 addresses in the IPv6 header could be compressed to
64 bits in some limited domain as long as _all_ the devices agree that
IPv6 addresses are 64 bits within the domain. The problem is that all
really means _all_, if even one node misses the news that addresses
have a different size then the node cannot correctly process packets--
this isn't just bad rouitng, it's fundamental and systematic
misinterpretation of a standard protocol and hence the protocol is not
robust and not backwards compatible.

Tom

>
>
>
> 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 <ipv6-bounces@ietf.org> On Behalf Of James Guichard
> Sent: 30 May 2020 23:05
> To: John Scudder <jgs@juniper.net>
> Cc: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
> 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 <jgs@juniper.net>
> Sent: Saturday, May 30, 2020 4:29 PM
> To: James Guichard <james.n.guichard@futurewei..com>
> Cc: Tom Herbert <tom@herbertland.com>; Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
> 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 <james.n.guichard@futurewei..com> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------