Subject: Re: Limited Domains:

From: Jiayihao <[email-masked]>
Date: Sat, 17 Apr 2021 03:44:56 +0000

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.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 17 Apr 2021 00:28:08 -0400

There are (at least) two very different situations.

Case one is an easily distinguished protocl with easy edge behaviors. 
MPLS is the canonical example.  SFC's NSH fits that bill.  SRH fits that 
bill.  It is a new extension that will not be misunderstood.  It is used 
only in limited domains for reasons of operability and security.  We do 
this a lot.

Then there is case two,  pretending a limited domain lets one 
re-interpret an existing field.  Since the field already has meaning, 
border filtering is difficult if not impossible.  And because it has an 
existing meaning, existing devices have to figure out whether they are 
to interpret the field in which of two (or more) incompatible ways.

That is a recipe for interoperability and operability failures.  It is 
just plain a bad idea.

Please do not use the examples of case one above as arguments for 
permitting case two above.

Yours,
Joel

On 4/16/2021 11:44 PM, Jiayihao 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.
> 
> 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.
> 
>>> [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.
> 
> 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.
> 
> 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 17 Apr 2021 14:55:11 +1000

On Sat, 17 Apr 2021, 13:45 Jiayihao, <[email-masked]> 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.
>
>
>
> 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.
>

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.
>
>
>
> 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.
>
> > [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.
>
> 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

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 19 Apr 2021 10:49:24 +0200

+1

As simple exaple: I for myself saw the 255 TTL security "protection" that
was supposed to prevent "attack-from-multiple-hops away" happily running
away in a network on bugs in forwarding path more than once ;-)

So yes, either air-gap or define a "non-compatible species" gap as in new
protocol format/codepoint, everything else is sophism not supported by real
experience.

-- tony

On Sat, Apr 17, 2021 at 6:56 AM Mark Smith <[email-masked]> wrote:

>> > [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] 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.
>>
>>
>>
>> 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.
>>
>> > [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