Re: Limited Domains:

On Sat, 17 Apr 2021, 13:45 Jiayihao, <jiayihao@huawei.com> wrote:

> argument 1:
>
> > [Gyan Mishra] There are so many variables and variations and nuances the
> idea of a “limited” or “closed” domain exists which could encompass all sub
> domains and thus in some cases that limited domain may not see that limited
> as it could be quite massive.
>
> >> [Brian] Limited domains exist for all kinds of reasons. Like it or not
> (and some people don't like it), the current architecture of the Internet
> includes thousands (probably millions) of limited domains.
>
>
>
> Yeah. Like it or not, limited domain is already a life of fact.
>
> One problem seems to be even we have define limited domain on RFC 8799,
> but there seems ‘views vary from person to person’. In fact, every global
> CDN network can be considered as a limited domain in general, Google WAN,
> AWS WAN for example. And this is align with the definition of RFC8799.
>
> So generally speaking, even QUIC can be regarded as a limited domain
> protocol philosophically.
>
>
>
>
>

Limited doesn't really exist if the domain talks the same protocol as
adjacent domains, and there are possibilities that a packet can
successfully escape one limited domain and successfully enter another.

Implementation bugs, hardware failures, operator configuration error and
default and aggregate routing create those possibilities.

Packets with Link-Local source or destination addresses are supposed to
have a limited forwarding domain limited to a link, yet we know packets
with LLA source addresses leak off of links due to destination only
forwarding implementations.

In other words, there hasn't been 100% success at creating the simple
limited domain of a link for LLA addressed packets, and that is supposed to
be an implementation default and is an RFC requirement. Good luck when it
depends on human operators to configure it.

Truly limited domains can only be created in two ways:

- A physical air gap

-  The ingresses to all adjacent domains have no possibility of accepting
and having any understanding of the local limited domain's packets if they
escape (e.g. an MPLS network trying to send packets into adjacent domains
that do not use MPLS at all).

IPv6, being an internetworking protocol, is specifically designed to be an
inter-domain protocol to facilitate internetworking networks and the hosts
attached to them. Trying to use it as a limited domain protocol is
fundamentally fighting against its design goals.

argument 2:
>
> > [Manfredi (US), Albert E] My main view is, if the domain is truly
> limited, firewalled or even air gapped, then what is the motivation to seek
> approval in a standards body?
>
> >> [Brian] On that argument the SPRING WG should never have been chartered
> and the 6MAN WG should never have approved RFC8754. Also, we should never
> have defined diffserv in 1998. And NAT, of course, would be excluded by
> definition, and RFC1918 from 1996 would need to be obsoleted.
>
>
>
> My point here is: it is not conflict.
>
> Protocol that works in a limited domain area like MPLS, SRv6 never
> built/rely on the concept of Limited domain. On the contrary, limited
> domain is a result of overall observation of the current technologies.
>
> So here comes to the reality: for every design that targeted for a limited
> domain scope, once it is targeted and going to be standardized by any SDO,
> then it will eventually to be adopted anywhere in the Internet-wide area.
>
> So the result is: for every STANDARDIZED “proprietary” tech which
> conceptually belongs to limited domain will actually be adopted in the
> Internet wide (if the value is acknowledged).
>
>
>
>
>
> argument 3:
>
> > [Robert] And I fully understand why this is going on like this - to make
> sure new features do not break existing IPv6 world ... it is just that
> protecting something which technically is already addressed and keeping
> innovation gated is IMO not the best strategy for networking.
>
> >> [Brian] Yes. That's exactly why I worked on RFC8799.
>
>
>
> Agree. One thing should care about as mentioned in RFC 8799 security
> consideration: “a protocol intended for limited use may well be
> inadvertently used on the open Internet, so limited use is not an excuse
> for poor security.” As silicon technique evolved, old-fashion/obsolete
> network design will be replaced by new design.
>
> Although consistency is quite important for IPv6 at this stage (which I
> agree as well), IPv6 will eventually face challenges one day.
>
>
>
> -----------
>
> Only thing we have to pay attention for is: we hate the pain of IPv4 to
> IPv6 upgrade, and we really don’t want such pain happened any more. I guess
> this is most concerns that many of us worrying for.
>
>
>
> My2cents,
>
> Yihao Jia
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>