Re: CRH and RH0

On Wed, May 13, 2020 at 8:35 AM Ron Bonica <rbonica@juniper.net> wrote:
>
> Tom,
>
> CRH is unique in that it requires a CRH-FIB. However, it doesn't require an special control plane support. The CRH-FIB can be created:
>
> - by configuration (CLI)
> - by a controller
> - by a IGP
>

Ron

Each of those are examples of additional control plane functionality
that creates state that has to be disseminated through the network. In
contrast, if RFC6554 is used then the route list just expands to
simple IP addresses that can be routed using the normal FIB. If all
the user wants to do is route their packets through specific nodes in
the network then this seems like a perfectly good solution. If they
want to perform "network programming" then I suppose they might need
the additional complexity of SIDs.

> I would still argue that CRH is a "general purpose" solution because:
>
> - It is applicable in a wide variety of use-cases
> - It doesn't rely on anything other than IPv6 cannon (e.g., RFC 8200, RFC 4291) and what is specified in the CRH draft.
>
> It's just another tool in the IPv6 tool box.

I agree it's another tool in the tool box and it's a clean model, but
I still wish there was a mode where it could just work "out of the
box".

Tom

>
>                                                                                                          Ron
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Tom Herbert <tom@herbertland.com>
> Sent: Tuesday, May 12, 2020 10:29 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: otroan@employees.org; 6man <6man@ietf.org>
> Subject: Re: CRH and RH0
>
> [External Email. Be cautious of content]
>
>
> On Tue, May 12, 2020 at 2:36 PM Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> >
> > Ole, Darren,
> >
> > The CRH is a general purpose Routing header that operates inside of a network domain. In the sense that it is a general purpose routing header, it replaces RH0. In the sense that it is restricted to a network domain, it does not replace RH0.
>
> Ron,
>
> Not to nit-pick, but doesn't CRH require a specific control plane to be useful which would make it less than general purpose? I don't believe RH0 had such a requirement. Also there's the RH in RFC6554 that has a similar goal in compressing the addresses in the routing header, but doesn't seem to require additional control plane logic either. I think these might be worth referencing.
>
> Tom
> ..
> >
> > If adding these two sentences will cause you to support the draft, or at least not object to it, I will happily add them!
> >
> > Are these the only objections?
>
> It would seem the goals of CRH are very similar to RFC6554 in compressing the addresses in the routing header. I think this might be worth referencing.
> >
> >
> > Ron
> >
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: otroan@employees.org <otroan@employees.org>
> > Sent: Tuesday, May 12, 2020 4:38 PM
> > To: Ron Bonica <rbonica@juniper.net>
> > Cc: Darren Dukes (ddukes) <ddukes@cisco.com>; 6man <6man@ietf.org>
> > Subject: Re: CRH and RH0
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Ron,
> >
> >
> > > The answer to your question is a bit nuanced. My goals were to build a general purpose routing header that overcomes the RH0's limitations. Those being:
> > >
> > >       - Its size
> > >       - Its security issues
> > >
> > > Now, is that a replacement for RH0? In one way, yes. RH0 and CRH are both general purpose routing headers. In another sense, no. RH0 is meant to traverse network boundaries. But RFC 5095 taught us that letting routing header traverse network boundaries might not be a wonderful idea. So, CRH is restricted to a network domain.
> >
> > If CRH could be a RH0 replacement, you would have to show how the tag distribution mechanism would work across the Internet?
> > RH0 was supported in every IPv6 node, given the requirement for a tag->IPv6 address (or is it forwarding method) mapping, I can't quite see how that would be done in a general enough fashion for CRH?
> >
> > I don't think RFC5095 taught us that source routing cannot be done across the Internet.
> > In fact I don't see how the CRH draft prevents the RFC5095 attack to happen inside of the CRH limited domain.
> > Just send a packet with a list of tag#0, tag#1, tag#0, tag#1 and you have the same amplification attack.
> >
> > > And now I return to my original question. When engineering students read the CRH RFC in 25 years, will they really care what my motivation was? Why should we burden them with this detail?
> >
> > To the contrary. Take the motivations and intentions behind IPv6. We
> > have spent thousands of emails trying to decode what the original
> > intensions with EHs and their limitations were, why the minimum MTU
> > was 1280, recently I saw a thread about the reasons for why TTL/HL and
> > protocol/next header was swapped between v4 and v6. If your protocol
> > is successful, the original napkin it was designed on will become
> > legend. ;-)
> >
> > Best regards,
> > Ole
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests:
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> > __;!!NEt6yMaO-gk!VCsmnDZrlJb72chjZsxpFTzE3HDirD3f2dZKrrUJjn1YVZWUhae_u
> > jIzFjntGXzC$
> > --------------------------------------------------------------------