WARTs and IPng

[Greg Minshall <[e-mail]>]

Hi, all.

After IPv4 was released, various things changed in its environment which
caused new features and hacks to be developed and glommed onto it.  Some of
these things have integrated in reasonably nicely; others stick out
horribly.  Additionally, because of the way things work, certain things we
might like to do are reasonably hard.

I would like to make sure that, to the extent possible, these issues are
addressed in IPng.

In order to do that, i have been attempting to collect a list of these
WARTs.  (Note that not all are "bad"; i think, however, that all are
accruals to IPv4 resulting from changes in the environment since the
initial deployment of IPv4.)

Here is the current (totally unprioritized) list.  If you have more, please
send them to me and i will add them.

Greg
----
Warts on IP and the Internet:

; New ICMP messages

        You'd like to send a new ICMP message to a host, but you don't know
if the host "groks" the new ICMP message (and, the message is "data
driven", eg, if the host doesn't change its send behaviour, you will
continue generating these new message types).

        Also (firewalls, security, etc.), need (? - nice to have?) some way
of saying "if you don't understand this, then SHUT UP!".

; Firewalls
        The existence thereof.  Because of non-research use of (connection
to) Internet.

        Recognize firewalls as a first class object in the architecture
(whatever that means).

        The desire of a firewall to know "when" "who" tried to ask "whom"
to do "what".

        Should this packet (e-mail message?  gasp!) ever leave this "site",
"company", "organization"...

; "Mask and Match"
        Hard to do ad hoc networking

; Priority queuing, fair queuing, etc.
        Because (?) of more traffic classes, shared usage by a larger
number of organiations/users; administrative policies.

        Some ??? way of describing priority and/or "slice of the pie" in a
packet (so the router doesn't have to grunge around in the packet).

; packet classifying
        Required for priority/fair queueing.

        A packet class field, with local or global significance.

; drop sets (w/in packet stream)
        For graceful degradation with newer (time-based) streams

        A field which describes a "drop set", precedence within that set, etc.

; link (and other resource) sharing
        Like priority/fair queueing.

        Fair queueing solution?

; routers need to look at all options (and shouldn't have to)
        Performance conflicting with desires for extensibility

        End-to-end options separate from hop-by-hop options.

; TMUX
        Performance for small packets to the same destination host

        Make it part of the base spec (if it were worth it)

; Fragmentation
        Doesn't carry total datagram length in fragments.  Doing it in
routers probably keeps sending host blissfully unaware of performance it is
incurring.

Previous hop versus source

        Sometimes you'd like to know the "previous hop" of a packet
(previous router).

RFC1577; "Classical IP and ARP over ATM"
        IP over different data links.

        Would it be enough to include the ATM node address as the IPng node
address?

RFC1560; "The Multiprotocol Internet"
        The Internet as a set of wires which connect the world so we want
to use those wires to support "all" of our applications.


RFC1548; "PPP"
        Light-weight connection to a network (and to the Internet).

RFC1546; "Host Anycasting Service"
        New idea - type-based addressing.

RFC1545; "FOOBAR"
        Multiprotocol.

RFC1542; "BOOTP"
        More hosts ==> management (configuration) harder.  So, make it easier.

RFC1541; "DHCP"
        == BOOTP.

RFC1519; "CIDR"
        Impose an N-level hierarchical addressing structure to simplify the
routing problem.

RFC1518; "Address allocation with CIDR"
        == CIDR.

RFC1510; "Kerberos"
        Larger user population, non-research use of Internet, coupled with
desire to protect resources.  Need to identify/authenticate principals

RFC1492; "An Access Control Protocol, Sometimes Called TACACS"
        ??? == Kerberos.

RFC1483; "Multiprotocol Encapsulation over AAL5"
        IP over various link layers.  IP over cell-oriented media. 
(Eventually, issues about cell drop probabilities ==> packet drop
probabilities.)

RFC1478; "IDPR"  (policy routing)
        Muliple policies in the routing infrastructures + source
sensitivity to routing.

RFC1433; "Directed ARP"
        IP over various media ???.

RFC1393; "Traceroute IP option"
        In general, traceroute is a hack to manage the network.  (Probably
a good wart...)

RFC1329; "ARP for dual MAC FDDI networks"
        ???

RFC1326; "Mutual encapsulation considered dangerous"
        Increased use of the Internet in order to achieve connectivity for
various protocols.  Reality that there are patches (large or small) where
any given protocol will not have connectivity (but needs connectivity).

RFC1322; "Unified approach to inter-domain routing"
        ???

RFC1306; "Experiences supporting by-request circuit switched T3 networks"
        ???

RFC1281; "Guidelines for the secure operation of the Internet"
        Lots of people, very open, Internet as environment for "mission
critical" applications, concern to protect assets/resources.

RFC1267; "BGP-3"
        Split between IGP and EGP; reflects the need to have clean
(well-defined, thus protected) borders between administrative domains.

RFC1256; "Router Discovery"
        Hosts aren't directly connected to routers (IMPs).  The fact that
with increased number of nodes, hand configuring the local router doesn't
work (especially if routers go down).

RFC1247; "OSPF v 2"
        RIP doesn't scale.

RFC1234; "Tunneling IPX through IP"
        Multiple protocols over the Internet; connectivity.

RFC1209; "Transmission of IP datagrams over SMDS"
        IP over various data links.

RFC1193; "Client requirements for real-time communications"
        New (time-based) applications.

RFC1191; "Path MTU discovery"
        Heterogeneous links + desire for increased performance.

RFC1190; "ST-II"
        Guaranteed performance for time-based applications.

RFC1144; "VJ compression"
        IP over low speed links, quickly.

RFC1141; "Incremental updating of the IP checksum"
        Better performance (for routing).

RFC1112; "IP Multicasting"
        1-N communications.

RFC1088; "IP over NetBIOS"
        Connectivity in a multi-protocol Internet.

RFC1075; "DVMRP"
        == IP Multicasting

RFC1058; "RIP"
        Need for routing at the network (rather than link == IMP) layer. 
Actually, wasn't this a key implication of catenet model?

RFC1035; "DNS"
        Larger number of name<>address bindings makes manual, centralized
table incorrect.

RFC1029; "Fault tolerant approach to ARP for multi-LAN system of ethernets"
        ???

RFC1027; "Using ARP to implement transparent subnet gateways"
        Well, make IP subnetting easier to use.

RFC950; "IP subnetting"
        Deal with scaling in number of wires.

RFC947; "Multi-network broadcasting in the Internet"
        There is more than one network in the Internet.

RFC922; "Broadcasting IP datagrams in the presence of subnets"
        Subnets exist.

RFC903; "RARP"
        Eliminate manual configuration, due to increased number of hosts.

RFC893; "Trailer encapsulation"
        Desire to have as efficient as possible a method of running IP over
a given data link.

RFC826; "ARP"
        There is no algorithmic mapping of IP address into data link address.