Notes from the 47th IETF meeting


Adelaide, Australia, 26-31 March 2000
Piers O'Hanlon, University College London
 

Introduction


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.
 

zeroconf

There was a discussion on the utility of SLP (Service Location Protocol) in zeroconf environments.

Dynamic Configuration of IPv4 link-local addresses

<draft-cheshire-ipv4-linklocal-00.txt>
Stuart Cheshire, Apple Computer

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

<draft-aboba-dnsext-mdns-00.txt>
Bernard Aboba, Dave Thaler, Microsoft

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.

MANET

Routing zones and bordercasting

<draft-ietf-manet-zone-zrp-03.txt>
http://www.ee.cornell.edu/~haas/wnlprojects.html#RWN
ZYGMUNT J. HAAS,  Cornell University

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).
 

Ad Hoc On-Demand Distance Vector (AODV) Routing - Update

<draft-ietf-manet-aodv-05.txt>
Charles Perkins, Nokia

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:

Optimized Link State Routing Protocol (OLSR)

<draft-ietf-manet-olsr-01.txt>

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:

Edge Mobility Architecture

<draft-oneill-ema-01.txt>
Scott Corson, University of Maryland
Alan O'Neill, BT

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.
 

Mobileip

Mobility Support in IPv6

<draft-ietf-mobileip-ipv6-11.txt>
Charles Perkins, Nokia

Updates:

IP Mobility Support for IPv4, revised

<draft-ietf-mobileip-rfc2002-bis-00.txt>
Charles Perkins, Nokia

Updates:

Reverse Tunneling for Mobile IP, revised

<draft-ietf-mobileip-rfc2344-bis-01.txt>

Updates:

AAA Registration Keys for Mobile IP

<draft-ietf-mobileip-aaa-key-01.txt>
C. Perkins, Nokia

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:

  1. Get new keys (expensive)
  2. Get from previous FA

ngtrans

Draft on Abuse of IPv6

http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt
Jun-ichiro itojun Hagino, Research Lab, IIJ

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.
 
 

Transition Mechanisms for IPv6 Hosts and Routers

<draft-ietf-ngtrans-mech-04.txt>
 

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:

Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels

<draft-ietf-ngtrans-6to4-04.txt>
Brian Carpenter

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.
 

Dual Stack Transition Mechanism (DSTM)

<draft-ietf-ngtrans-dstm-01.txt>

It is now in BSD stack from INRIA:

DHCPv6 is being worked on concurrently.
 

A SOCKS-based IPv6/IPv4 Gateway Mechanism

<draft-ietf-ngtrans-socks-gateway-04.txt>
H. Kitamura, NEC Corporation

Available from http://www.socks.nec.com which has apparently had 5000 downloads.
 

Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication

<draft-ietf-ngtrans-translator-03.txt>

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
 

IPv6 Tunnel Broker

<draft-ietf-ngtrans-broker-02.txt>
Alain Durand

Suggests a new 'Tunnel Broker' to automatically manage tunnel requests coming from the users.
 

An IPv6-to-IPv4 transport relay translator

<draft-ietf-ngtrans-tcpudp-relay-00.txt>

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.
 

Tunnel endpoint discovery

Granularity of tunnel end point discovery mechanism: Tunnel broker: DNS is the natural distribution model but DNS shouldn't be overloaded. However it was suggested that with the creation of a tunnel6.int top-level domain it could be used for lookups.
 

mobileip

Private IP Encapsulation within IP (PIPE)

<draft-petri-mobileip-pipe-00.txt>
Petri Bernhard

It is an extension of IP in IP from rfc2003. Adds the use of realms by way of a vpn-id (rfc2685):

Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network

<draft-ietf-mobileip-3gwireless-ext-03.txt>

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.
 

Route Optimization in Mobile IP

<draft-ietf-mobileip-optim-09.txt>

The Route Optimization Authentication Extension now includes subtype when authenticator value is computed:

Registration Keys for Route Optimization

<draft-ietf-mobileip-regkey-01.txt>

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:

AAA is not considered.

Uses Generic key distribution extensions.
 

Universal Mobile IP (UMIP) Location Management

<draft-wang-mobileip-umip-00.txt>

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.
 

Generalized NAI Extension (GNAIE)

<draft-mkhalil-mobileip-gnaie-00.txt>

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.
 

Mobile IP Session Identifier Extension

<draft-ietf-mobileip-sessionid-00.txt>

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.
 

Application Protocol BOF

On the Design of Application Protocols

<draft-mrose-blocks-appldesign-01.txt>
M.T. Rose

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

 

Inter-Domain Multicast Routing WG (idmr)

Mtrace

<draft-ietf-idmr-traceroute-ipm-06.txt>
Bill Fenner
mtrace goes to last call.(bogons documented)
 

IGMPv3

<draft-ietf-idmr-igmp-v3-02.txt>
Isidor Kouvelas, Cisco

An updated spec missed the I-D deadline. New version should be ready for last call.
UPdates:

Query packet format, new fields for:

Host side changes Router side changes

Socket Interface Extensions for Multicast Source Filters

<draft-ietf-idmr-msf-api-00.txt>
Dave Thaler, Microsoft

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.
 

IPv6 MIBs

Dave Thaler

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.
 

UniDirectional Link Routing (udlr)

As regards security it was pointed out that effective ingress filtering cannot be done as traffic may be legally sourced from anywhere.

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.
 

IPNG

Going to last call: Going to last call informational: Ready for last call:

Default Address Selection for IPv6


<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:

Not clear which approach to take. MUST or SHOULD (probably).
Privacy and src address selection - when to use public vs anon addr options: Integration with IPv4

IPv6 hooks for AAA registration and "host routing"

<draft-nordmark-ipv6-aaa-hooks-00.txt>

ISP might want one or more A's from AAA.
Registration request sent to AAAL addr
 

AAA for IPv6 Network Access

<draft-perkins-aaav6-00.txt>
Auth net access for ipv6
Where to:
addr of AAA from routers
This document proposes a way for IPv6 nodes (clients) to offer credentials to a local AAA in order to be granted access to the local network.  Whereas for IPv4 it is not clear that routers and DHCP will be equipped to handle such functions, we believe that it is more efficient and thus reasonable to expect such access controls to be exerted by IPv6 routers, possibly as part of performing their role as DHCPv6 relays.  DHCPv6 servers and routers are expected to work in conjunction with AAA servers to determine whether or not the client's credentials are valid.

So AAAF(foreign) talks to AAAH(home) sending solicitation with credentials & MN-NAI Router returns Router Advertisement.

Issues:

ICMP trace back BOF


Some papers:
http://www.cs.washington.edu/homes/savage/traceback.html
ftp://ftp.tislabs.com/pub/IDIP/DISCEX_IDR-Infrastructure.pdf
 

ICMP Traceback Messages

<draft-bellovin-itrace-00.txt>
Bellovin, AT&T labs

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