Changes between Version 165 and Version 166 of WikiStart


Ignore:
Timestamp:
12/08/19 19:48:28 (3 years ago)
Author:
warren@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart

    v165 v166  
    1212
    1313The below are some things to consider and keep in mind while writing Internet Drafts, both in the Operations and Management area, but also in the IETF in general.
     14
     15
     16There are many ways to shoot yourself in the foot when writing an Internet Draft - here are some of the ways that the current AD has seen this happen and / or things which it is worth keeping in mind.
     17
     18Note that these are just the personal views and advice from the current OpsAD - it is far from complete, feel free to send me additional pointers / ways which you've seen people trip over operational bits.
     19
     20RFC 5706 Appendix A. - "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (https://tools.ietf.org/html/rfc5706) contains a checklist which is also very helpful.
     21
     22
     23
     24=== DNS ===
     25
     26
     27DNS is core plumbing, and as such it is one of the obvious tools in the protocol designer's toolbox. There are, however, a number of dangers here.
     28
     29These include:
     30
     31-  Trying to use a name in the "rightmost" (TLD) part of the name - this is almost definitely doing to end poorly for you. For a small subset of issues with this see:
     32  - RFC 8244 - Special-Use Domain Names Problem Statement
     33  - RFC6761 - Special-Use Domain Names
     34  - IAB statement on the registration of special use names in the ARPA domain
     35  - Guidelines for Use of the Special Use Names Registry ("work in progress.")
     36- Assuming that the "reverse DNS" tree (in-addr.arpa) is complete and / or up to date and / or reflects reality. Periodically it is assumed that publishing security or similar information at e.g 1.2.0.192.in-addr.arpa.is safe because only the "owner" of 192.0.2.1 controls this. This is sadly incorrect.
     37- Mistakenly thinking that DNS is a UDP only protocol (and / or that TCP is only used for zone transfers). Additional reading: RFC7766 - DNS Transport over TCP - Implementation Requirements
     38- Using DNS TXT records. While the DNS can store TXT records (RFC1464), it is almost definitely a mistake to develop a protocol which uses these. A new DNS RRType is much preferred - it makes it easier to parse, and is less likely to break things. See RFC6895 -  Domain Name System (DNS) IANA Considerations, Section 3.1 for more detail.
     39- Incorrect usage of the _underscore naming pattern - see RFC8552 - Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves for advice on how to use these.
     40
     41=== IPv6 ===
     42
     43- Due to various hardware limitations, packets with "excessive" IPv6 Extension Headers may be dropped. Various operators also filter packets with extension headers and or fragments - see the (expired) draft "Why Operators Filter Fragments and What It Implies"(https://www.ietf.org/archive/id/draft-taylor-v6ops-fragdrop-02.txt) for more background.
     44
     45
     46=== Routing ===
     47
     48- Assuming that "customers" connect to Tier-2 ISPs who then connect to Tier-1 ISPs. The routing system is much more messy than this, and "customers" and various size ISPs all peer / purchase transit / etc.
     49- Assuming that sending a packet which needs "high-touch" (the control plane) of a router is a reasonable thing to do. In order to scale, modern routers do almost all work in dedicated network hardware. Anything which requires punting transit traffic to the control plane almost definitely means that the traffic will be dropped / that the protocol will not be deployable.
     50- Assuming that Quality of Service markings will cross administrative boundaries.
     51 
     52
     53
     54
    1455
    1556=== Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions ===