Adelaide, Australia, 26-31 March 2000
Piers O'Hanlon, University College London
This report provides a summary of discussions which took place during
the 47th IETF meeting, held between 26th and 31st March 2000 in Adelaide,
Australia. The contents of this document are based on personal notes taken
during the meeting, and do not provide an official record of the meeting.
The official proceedings are available from the IETF web site.
The opinions and interpretations expressed herein are those of the author, and do not necessarily represent those of the IETF, the working group chairs, or other persons mentioned herein. If this document differs in its record of events from the official proceedings of the meeting, then those proceedings should be considered accurate.
The remainder of this document is organised according to working group
or BOF title.
When a host wishes to configure a link-local address, it selects an
address at random from 169.254/16 (IANA allocated). It uses ARP to resolve
conflicts to find or reallocate new address. Win98 and MacOS 8.5 (and later)
use a scheme similar to this draft ( see also rfc2563.txt and draft-ietf-dhc-ipv4-autoconfig-05.txt).
It is less well defined for with machines that have multiple interfaces
and/or multiple addresses per interface. Steve Deering raised the point
about source address selection when more than once address was assigned
to an interface or machine and suggested they look over the work in IPNG.
Multicast DNS (mDNS) is an extension to the DNS protocol which consists of a single change to the method of use, and no change to the format of DNS packets. Basically hosts send and respond to queries on port 53. DHCP precludes mDNS.
The hybrid Zone Routing Protocol (ZRP) can adapt to a wide variety of network scenarios by adjusting the range of the nodes' proactively maintained routing zones. Large routing zones are preferred when demand for routes is high and/or the network consists of many slowly moving nodes. On the other hand, smaller routing zones are appropriate in situations where route demand is low and/or the network consists of a small number of nodes that move fast relative to one another.
The global reactive component of the Zone Routing Protocol (ZRP) uses the unicast/multicast based "bordercast" mechanism to propagate route queries throughout the network, rather than neighbor-broadcast based flooding found in tradtional reactive protocols. Bordercasting leverages knowledge of local network topology to direct route queries away from the source, thereby reducing redundancy.
The ZRP consists of two components, the proactive IntrAzone Routing Protocol (IARP), and the reactive IntErzone Routing Protocol (IERP). The ZRP philosophy allows for a great degree of flexibility in the implementation of either component.
Using OPNET link state and distance vector versions of the IARP have
been developed. Their basic operation is similar to traditional protocols
like OSPF [G] and RIP [H], except that the propagated route information
is restricted to the scope of a routing zone (controlled by means of a
hop count field).
The Ad Hoc On-Demand Distance Vector (AODV) algorithm enables dynamic, self-starting, multihop routing between participating mobile nodes wishing to establish and maintain an ad hoc network.
There was an update that covered a problem when participating systems reboot and forget routing info causing routing loops. To prevent this possibility, each node on reboot waits for DELETE_PERIOD. In this time, it does not respond to any routing packets.
For IP address autoconfiguration the comparsion was made with zeroconf use of 169.254/16 and Duplicate Address Detection (DAD). AODV does not provide ARP so instead the use of RREQ (route request) using the selected source address (from 169.253/16). It retries and takes the address if no RREP is received.
Other issues:
The protocol is an optimization of the pure link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs).
Implementations:
The context is that a special form of routing is required when there are stable networks in the core but mobile nodes on the edges.
This draft concurs with the authors of Cellular IP and HAWAII regarding the need for domain-based routing support in handling edge mobility. It suggests that a general routing solution might be advantageous and presents the loose framework of a possible routing architecture. It also suggests a specific protocol based on TORA for the implementation of such an architecture.
The protocol based on TORA exploits soft handover on CDMA.
Updates:
Updates:
Updates:
MN can't communicate with AAA to get keys - Need HA to send keys from AAA to MN. The document specifies extensions to the Mobile IP Registration Reply packet that can be used to distribute such security information to the mobile node.
FA keys encoded as Opaque tokens for use in hand-off process
Problem: Getting AAA keys, either:
Mostly complaints about no checking of src and destination addresses
in host implementations when doing automatic conversion of emdebbed IPv4
addresses and 6 to 4 packets 2002::xx . Referrred to rfc 2267 for protection:
Network Ingress Filtering: Defeating Denial of Service Attacks which employ
IP Source Address Spoofing.
When doing Neighbor Discovery over Tunnels not LLA options should be sent and those that are recieved should be silently ignored.
After the decapsulation of an IPv6, in IPv4, the node should silently discard a packet with an invalid IPv6 source address, including:
Question was raised as whether there should be a link local addr on 6to4 interface. Concluded that since it wasn't really used it was not needed.
Question as to how to do Multicast - Use PIM-SM. However any form of flooding cannot be used as this would require all existing 6to4 routers to consider themselves as neighbours simultaneously. i.e. it is like an NBMA network.
Host only 6to4 will be a seperate draft.
It is now in BSD stack from INRIA:
Available from http://www.socks.nec.com
which has apparently had 5000 downloads.
Three translation mechanisms are described. From the address mapping point of view, the translators are categorized into four types and each feasibility is considered.
Out of scope: SOCKS, Stateless IP/ICMP Translation Algorithm (SIIT),
BIS
Suggests a new 'Tunnel Broker' to automatically manage tunnel requests
coming from the users.
The draft describes an IPv6-to-IPv4 transport relay translator.
It
enables an IPv6-only node to exchange TCP or UDP traffic with IPv4-only
nodes. A transport relay translator box, which sits in the middle,
will
take care of the protocol translation. Uses a 'dummy prefix' in a modified
DNS which hosts use when attempting to talk to an IPv4 host.
Implemented in KAME.
It is an extension of IP in IP from rfc2003. Adds the use of realms by way of a vpn-id (rfc2685):
This document defines extensions to the Mobile IP protocol to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network.
It defines how mobility is managed over the RP interface (between the
Radio Network Node (RNN) and the Packet Data Serving Node (PDSN)). Uses
port number 451 for access to RP.
The Route Optimization Authentication Extension now includes subtype when authenticator value is computed:
Route optimization defines extensions to Mobile IP Registration Requests that allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding. These extensions for smooth handoff require a registration key to be established between the mobile node and foreign agent.
The ways to get the keys are:
Uses Generic key distribution extensions.
A system for avoiding triangle routing in Mobile IP by providing location registration (LR) nodes.
This was presented at the Washington IETF - it was decided that is was
too big a redesign and thrown out.
The Mobile IP Extensions Rationalization (MIER draft-mkhalil-mobileip-mier-03.txt)
specification defines a new extension header format, that is intended to
extend the Mobile IP extension address space. The Generalized Network Access
Identifier (NAI) extension, should be used by any Mobile IP extension
specifying an extension containing an NAI.
The Network Access Identifier can be added to a Mobile IP registration
request to identify the user and to allow the assignment of a dynamic home
address. However, users may want to open several simultaneous sessions
using the same NAI from the same or different devices and to obtain a unique
IP address for each session. The Mobile IP Session Identifier Extension
defined in this draft can be used to distinguish registration requests
belonging to these various sessions. It's like a remote DHCP.
Introduced the topic by trying to catagorise protocols into different groups based on their behaviour as regards: framing, encoding, Error reporting, multiplexing, user Authentification, and Transport Security. Three examples were brought out: SMTP, FTP, HTTP and broken down according to how they faired in each category.
Based on this a generic application protocol BXXP that exhibit certain features:
| Mechanism | BXXP |
|---|---|
| Framing | Counting, with a trailer |
| Encoding | MIME, defaulting to text/xml |
| Error Reporting | 3-digit and localized textual diagnostic |
| Multiplexing | channels with TCP-style flow control |
| User Authentication | SASL |
| Transport Security | TLS |
An updated spec missed the I-D deadline. New version should be ready
for last call.
UPdates:
Query packet format, new fields for:
Goals - to present a version independent API not present in 2553.
Basic API
Uses delta operations {ADD, DROP}_MEMBERSHIP, ALLOW
Advanced API
Allows multiple src in an atomic operation.
Question over whether to use setsocketopt() or ioctl() for
SIO_GET_MULTICAST_FILTER: to retrieve the list of source addresses
that comprise the source filter along with the current filter mode.
(Can't use setsocketopt() as it doesn't provide a method to return information in the call so ioctl has to be used although its not quite 'correct').
For proto indepedent API should use Interface index - this will be present
in IPv4 as well as IPv6.
Noted that RFC2465 defines an IPv6Address type. For IPv6 specific MIBS
and draft-ops-endpoint-mib-07.txt a protocol independent InetAddress
type is defined.
Various implementations were mentioned from:
Alcatel, Sony, Hitachi
The working group will be 'put to sleep' whilst draft is finished and
other items are tidied up.
<draft-ietf-ipngwg-default-addr-select-00.txt>
R. Draves, Microsoft Research
Uses a default policy table
For multihomed hosts choosing their src addr, there are two models;
These were discussed as outgoing, but each has a version for incoming
too:
ISP might want one or more A's from AAA.
Registration request sent to AAAL addr
So AAAF(foreign) talks to AAAH(home) sending solicitation with credentials & MN-NAI Router returns Router Advertisement.
Issues:
Some papers:
http://www.cs.washington.edu/homes/savage/traceback.html
ftp://ftp.tislabs.com/pub/IDIP/DISCEX_IDR-Infrastructure.pdf
Questions;
Will ISP's permit a mechanism that will express topology
Privacy implecations
What Auth mechanism is best
Marcus leach has a linux implementation using libpcp + GNU MP
Itrace packets are generated one in every 20,000 packets
Partial deployment would be useful.
Doc editor choosen: Jayhawk