Connected: An Internet Encyclopedia
APPENDIX C. FUTURE DIRECTIONS
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1812
Prev: APPENDIX B. GLOSSARY
Next: APPENDIX D. Multicast Routing Protocols
APPENDIX C. FUTURE DIRECTIONS
APPENDIX C. FUTURE DIRECTIONS
This appendix lists work that future revisions of this document may
wish to address.
In the preparation of Router Requirements, we stumbled across several
other architectural issues. Each of these is dealt with somewhat in
the document, but still ought to be classified as an open issue in
the IP architecture.
Most of the topics presented here generally indicate areas where
the technology is still relatively new and it is not appropriate to
develop specific requirements since the community is still gaining
operational experience.
Other topics represent areas of ongoing research and indicate areas
that the prudent developer would closely monitor.
Note: This list has been renumbered during convertion to HTML
- SNMP Version 2
- Additional SNMP MIBs
- More detailed requirements for leaking routes between routing
protocols
- Router system security
- Routing protocol security
- Internetwork Protocol layer security. There has been extensive
work refining the security of IP since the original work writing
this document. This security work should be included in here.
- Load Splitting
- Sending fragments along different paths
- Multiple logical (sub)nets on the same wire. Router
Requirements does not require support for this. We made some
attempt to identify pieces of the architecture (e.g., forwarding
of directed broadcasts and issuing of Redirects) where the
wording of the rules has to be done carefully to make the right
thing happen, and tried to clearly distinguish logical
interfaces from physical interfaces. However, we did not study
this issue in detail, and we are not at all confident that all
the rules in the document are correct in the presence of
multiple logical (sub)nets on the same wire.
- Congestion control and resource management. On the advice of
the IETF's experts (Mankin and Ramakrishnan) we deprecated
(SHOULD NOT) Source Quench and said little else concrete
(Section 5.3.6).
- Developing a Link-Layer requirements document that would be
common for both routers and hosts.
- Developing a common PPP LQM algorithm.
- Investigate of other information (above and beyond section
[3.2]) that passes between the layers, such as physical network
MTU, mappings of IP precedence to Link Layer priority values,
etc.
- Should the Link Layer notify IP if address resolution failed
(just like it notifies IP when there is a Link Layer priority
value problem)?
- Should all routers be required to implement a DNS resolver?
- Should a human user be able to use a host name anywhere you can
use an IP address when configuring the router? Even in ping and
traceroute?
- Almquist's draft ruminations on the next hop and ruminations on
route leaking need to be reviewed, brought up to date, and
published.
- Investigation is needed to determine if a redirect message for
precedence is needed or not. If not, are the type-of-service
redirects acceptable?
- RIPv2 and RIP+CIDR and variable length network prefixes.
- BGP-4 CIDR is going to be important, and everyone is betting on
BGP-4. We can't avoid mentioning it. Probably need to describe
the differences between BGP-3 and BGP-4, and explore upgrade
issues...
- Loose Source Route Mobile IP and some multicasting may require
this. Perhaps it should be elevated to a SHOULD (per Fred
Baker's Suggestion).
Next: APPENDIX D. Multicast Routing Protocols
Connected: An Internet Encyclopedia
APPENDIX C. FUTURE DIRECTIONS