Subject: MUST is an aspiration

From: Mark Smith <[email-masked]>
Date: Thu, 12 Sep 2019 12:19:17 +1000

We're seeing drafts that keep saying the inserted EH MUST be removed at
network egress, and therefore then use that to justify saying EH insertion
is fine.

I'd like to meet the people who have developed protocol implementations
that are and always will be bug free, never partially fail, and are always
100% configured correctly.

If they don't exist (they don't), then such a MUST in an RFC is an
aspiration. It's a theoretical goal, one that in practice has been proven
not to be 100% true in similar scenarios where things "MUST" not leak  (RFC
1918 leaks, route leaks, DNS PTR lookup for private addresses etc.)

Identifying packets with inserted EHs to then remove the EH is more
complicated that DA matching, which would be used with EH addition through
encapsulation. More complexity results in more likelihood of bugs and more
failure modes.

MUST is aspirational for DA matching (due to bugs, misconfiguration etc.),
it is even more so for complex EH insertion/subtraction operations.

If an additional IPv6 packet header causes too much overhead when used to
add local network information to an existing packet transiting a domain,
then IPv6 is the wrong tool for the job.

IPv6 packet headers are large because IPv6 addresses are large, and they're
large because they need to uniquely identify all devices attached to the
global IPv6 Internet.

For additional supplemental information limited to the local network, the
devices that only need to receive it is limited to those within the local
network that is adding the supplemental information. The only addressing
requirement here is to be able to uniquely identify the devices within the
network that will be adding and processing the local network's supplemental
information.

A much smaller encapsulation, to carry the local network supplimentary
information,  with much smaller addresses can be used, such as MPLS or IPv4.

IPv6 would be fine to use without modification if it didn't cause
unacceptable problems. Apparently does, motivating EH insertion to reduce
overhead. It's not the right tool for the job if its architecture has to
compromised to suit.

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 Sep 2019 12:07:27 +0300

On Sep 12, 2019, at 5:19 AM, Mark Smith <[email-masked]> wrote:
> If they don't exist (they don't), then such a MUST in an RFC is an aspiration. It's a theoretical goal, one that in practice has been proven not to be 100% true in similar scenarios where things "MUST" not leak  (RFC 1918 leaks, route leaks, DNS PTR lookup for private addresses etc.)

For the record, I doubt that “MUST” was ever something observed, at least following the publication of RFCs 1122/1123/1812. The first use was in RFC 1122/1123 and 1812, and in those it was something that was true of an algorithm - if <something> wasn’t the case (such as if ARP was sent FROM a broadcast address), something decidedly and demonstrably failed. In subsequent specifications, it was always something those participating in the relevant consensus wanted to be true, and gave them a tool to say to a developer or vendor that they had to MAKE true. Hence the logic behind “SHOULD”; the developer could point out a case where a “MUST” requirement didn’t work, and they were asked to document it. 

Something I have observed about specifications that presumed that they only applied in a defined corner of the Internet (usually in enterprise or residential networks, but in this case is an AS that uses the capability) was that they invariably made it out of the hinterlands onto the backbone. The most obvious cases are private and Martian addresses, but they are not the only ones, by a long shot. Hence, it seems to me that while the requirement is that “the hinterland should not let this out”, the practical requirement is that if you connect in some way with such a hinterland, you should implement defensive measures in case they do. Again, BGP is the obvious example - “you should not advertise ULA or private addresses”, and “you should filter out announcements from your neighbor of private and ULA addresses” - barring an agreement to the contrary.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 12 Sep 2019 09:43:50 -0400

> Something I have observed about specifications that presumed that they only applied in a defined corner of the Internet (usually in enterprise or residential networks, but in this case is an AS tha…

... it's worse than that / some more concrete data:

RFC6996 (Autonomous System (AS) Reservation for Private Use) speaketh thusly:
"If Private Use ASNs are used and prefixes originate from these ASNs,
Private Use ASNs MUST be removed from AS path attributes (including
AS4_PATH if utilizing a four-octet AS number space) before being
advertised to the global Internet."

but looking on routeviews shows there to be (assuming I've gotten my
regexp right  -- show ip bgp regexp
_(6451[2-9]|645[2-9][0-9]|64[6-9][0-9][0-9]|65[0-4][0-9][0-9]|655[0-2][0-9]|6553[0-5])_
): Displayed  573 routes and 13092222 total paths

RFC1918 doesn't contain RFC2119 language, but it does make it clear
that this space should be filtered out of routing announcements -- and
yet (using RV again) we see 7 routes for RFC1918 space (5 for
10.0.0.0/8 and 2 for 192.168.0.0/16).

Routing information is (relatively) easy to control the flow of, but
filtering IP packets at the border is operationally trickier, and will
leak more...

W

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf