R&D N 4/2005
Marius Clemetsen, Geir Egeland, Paal Engelstad,
Frode Kileng
Report from IETF meeting
attendance 2004
http://www.unik.no/personer/paalee
Report from IETF meeting attendance 2004
R&D Scientific
Doc.
Title
ISBN
ISSN
Project No
Program
Security Gr.
No. of pages
Date
N 4/2005
Report from IETF meeting attendance 2004
0809-1021
TFSS84
OPEN
40
2005.02.03
Author(s)
Marius Clemetsen, Geir Egeland, Paal Engelstad, Frode Kileng
Subject headings
IETF reports 2004
Abstract
This document presents the reports from the three IETF (Internet Engineering Task Force)
meetings held in March, August and November of 2004. A selected set of working groups
is covered, and these fall into the following main categories: Authentication in access
networks, IPv6, Mobility and Multicast Routing. The document provides short reports from
the working group meetings, the BoFs (Birds of a Feather) that have been attended, as well
as the plenary sessions. The document also summarizes the highlights from 2004.
Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
© Telenor ASA 2005.02.03
All rights reserved. No part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying, recording, or by any
information storage and retrieval system, without permission in writing from the publisher.
Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
Contents
1
Introduction ................................................................................1
1.1
Highlights from 2004......................................................................................... 1
2
Reports from Plenary Sessions ................................................3
3
Reports from selected IETF working groups ...........................8
3.1
3.1.1
3.1.2
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.4
3.4.1
3.4.2
3.4.3
3.4.4
Authentication in access networks..................................................................... 8
EAP (Extensible Authentication Protocol) ........................................................ 8
PANA (Protocol for carrying Authentication for Network Access)................ 10
IP version 6 ...................................................................................................... 12
IPv6 (IP Version 6 Working Group)................................................................ 12
Multi6 (Site Multihoming in IPv6).................................................................. 14
V6ops (IPv6 Operations) ................................................................................. 15
Mobility ........................................................................................................... 19
Capwap (Control And Provisioning of Wireless Access Points)..................... 19
DNA (Detecting Network Attachment)........................................................... 21
MANET (Mobile Ad-hoc Networks) .............................................................. 22
MIP4 (Mobility for IPv4) ................................................................................ 24
MIP6 (Mobility for IPv6) ................................................................................ 25
Mobike (IKEv2 Mobility and Multihoming)................................................... 27
Nemo (Network Mobility)............................................................................... 29
Routing ............................................................................................................ 30
L3VPN (Layer 3 Virtual Private Networks).................................................... 30
MBoneD (MBONE Deployment).................................................................... 31
PIM (Protocol Independent Multicast) ............................................................ 35
RMT (Reliable Multicast Transport) ............................................................... 36
4
Reports from BoF sessions.....................................................37
4.1.1
4.1.2
PERM (Protected Entertainment Rights Management) BoF ........................... 37
IPv6 over IEEE 802.15.4 BoF ......................................................................... 37
Significance for Telenor.....................................................................40
Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
1 Introduction
This document presents the reports from the three IETF (Internet Engineering Task Force)
meetings of 2004.
The meetings attended were:
•
IETF 59 in Seoul, South Korea (February 29. – March 4)
•
IETF 60 in San Diego, USA (August 1-6)
•
IETF 61 in Washington D. C., USA (November 7-12)
A selected set of working groups is covered. The document provides short reports from the
working group meetings, the BoFs (Birds of a Feather) that have been attended, as well as
the plenary sessions. The document also summarizes the highlights from 2004.
The main work in following up IETF in Telenor R&D is today carried out by a few people
(for 2004 it was: Marius Clemetsen, Geir Egeland, Paal Engelstad, and Frode Kileng). This
means that only a selected set of groups can be covered, and these fall into the following
main categories:
•
Authentication in access networks
•
IPv6
•
Mobility
•
Multicast Routing
Currently IETF is divided in 8 areas: Applications Area (16 groups), General Area (3),
Internet Area (20), Operations and Management Area (23), Routing Area (14), Security
Area (23), Sub-IP Area (1) and Transport Area (26). The total number of groups (per 4/12005) is 126.
1.1
Highlights from 2004
There has been a discussion in the IETF for the last couple of years regarding conceived
problems in the way the IETF operates. During the last part of 2003 the "problem" working
group was started to look into this, and the group produced 2 documents1 that describe the
problems and possible solutions. The group has now finished, but other groups have been
started to work further on the problem resolution process - newtrk (New IETF Standards
Track Discussion) and icar (Improved Cross-Area Review). These groups are concerned
with the IETF standards process and the document review process. There has also been an
initiative to improve the training of IETF participants (Education Team,
http://edu.ietf.org/). At the last IETF meeting (November 2004), as an example, there were
several training sessions (for newcomers, editors and chairs). There have also been efforts
to improve the processing of documents. There has been work to improve the RFC Editor
function, and "The Process and Tools (PROTO)" team has been created
(http://www.mip4.org/proto) to improve the speed of document processing in the IESG and
to produce tools for this. There has also been work on improving the handling of IPR
1
"IETF Problem Statement" (May 2004, RFC 3774) and "IETF Problem Resolution Process" (August 2004,
RFC 3844)
Telenor R&D N 4/2005 - 1
Report from IETF meeting attendance 2004
(Intellectual Property Rights), and there is now an IPR section in the RFC-format. The
improvement of the IETF processes has been a hot topic at plenary meetings.
In 2004, a challenge was raised to start addressing mechanisms for splitting locators and
identifiers, an issue that may solve problems common for several working groups. The
current use of an IP address as both an identifier and the specification for an Internet
network connection point is a source for many challenges when addressing solutions for
mobility and multi homing. The challenge has been taken on in several WGs and has made
the word ”Shim Layer” a well-known phrase throughout the IETF. A ”Shim Layer”
typically describes an indirection layer supporting the lookup and management of a
locator/identifier split. There exist separate working groups in IETF (hip - Host Identity
Protocol) and IRTF (hiprg – Host Identity Protocol Research Group) addressing this issue.
The hip working group is working on a protocol specification. There are several
implementations of the hip protocol already, but more experimentation and evaluation is
needed to come to any conclusion on the usefulness of hip.
Up till now, the standardization of communications above the MAC layer for small device
communication has typically been handled in industrial consortiums. Examples are
Bluetooth and ZigBee. In the end of 2004 there was much interest in the foundation of a
new WG to address issues related to the mapping of IP over small devices. The new WG
6lowpan will focus on the standardization of IPv6 over 802.15.4, i.e. an alternative to the
ZigBee specifications.
Spam has been identified as a major problem, and the IRTF research group ASRG (AntiSpam Research Group) was created in 2003 to develop tools and techniques to reduce this
problem. There was a presentation from the group at the IETF Planning Meeting of IETF
60.
2 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
2 Reports from Plenary Sessions
IETF 61 (Frode Kileng):
Harald Alvestrand presented the usual statistics: 1314 attendees at IETF 61 compared to
1469 in San Diego and 1314 in Seoul. Attendants from 26 countries were present (going
down). 4 new WGs have been created, 11 have finished and 92 RFCs has been published
since the last meeting.
The location for the next three meetings has been fixed: IETF 62 march 6-11 in
Minneapolis (No sponsor), IETF 63 July 31to August 5 in France (Sponsor: France
Telecom) and IETF 64 November 6-11 somewhere in Canada (Sponsor: Nortel).
The report from the RFC Editor showed that the "queue-problem" seems to be solved after
this problem has been addressed by using a professional copyeditor to reduce the backlog.
The IANA report also shows that the queue now is down to 4 weeks after hiring new staff.
Also the report from the IESG operations showed that the draft processing has improved.
In the review of the IAB Architectural Activities, Leslie Daigle requested input on
architectural implications of link layer indications (draft-iab-link-indications). Pete Resnick
then presented results from the IAB messaging workshop. The S-word (SPAM) was not
mentioned in fear of wrecking the workshop. The workshop identified the following items
as engineering topics: inter-protocol identifiers for messages and parts, and simpler key
distribution. Identified research topics include automated "introductions" and multitransport messaging. Architectural topics include threads and conversation management
and inter-protocol trust-model. IAB is thinking of future workshops as follow-ups to this
one.
The administrative restructuring was the main theme for this plenary also. Leslie presented
the current status: After a voting on the mailing list, there's consensus to move the
administrative activities of IETF to ISOC. This will not affect the technical processes of the
IETF. After finalizing the draft (December 1 2004), the draft will get full BCP approval
(last call 1/12-28/12, IESG approval January 6 2005) before doing any restructuring
actions. Then nomcom will be asked to fill the nomcom IOC slots. The hiring process of an
IAD (IETF Administrative Director) will be negotiated in March 2004. Questions from a
participant made it clear that the new organization may be more expensive in the short run,
but in longer term its uncertain. Bob Kahn said that since it is not clear where IETF actually
wants to go, the changes to the organization should be minimal. Harald felt that they only
do a minimal change now to make a necessary improvement of the administrative tasks of
IETF. Several others plead to slow down the restructuring to make sure the job is done
properly. A voting showed that the majority felt that the restructuring process is done as
fast as it should (against to fast or to slow. Another person wanted a voting option for "don't
bother us"!). During the discussion, several made hints to rumors about some hidden
tactics/positioning to place certain people in certain roles. Bob Kahn answered this and told
that "something has been going on" but it has been done with the best intentions for the
community. He told that "someone" was searching for a person to fill a PR-role and "some
people" "look after" the changing process. Due to liability issues he told that he couldn't go
into any details. Harald told that he wasn't informed about this and that for "hidden
processes", people just has to go to Bob Kahn.
In the joint IAB/IESG Open Plenary one person plead to stop using IPv6 as a term but just
IP since talking about several versions makes diversity. A plea for mechanisms in IETF to
handle IPR issues was also raised. Harald felt that this was difficult and an IESG member
answered that he couldn't see anything that could motivate to create this. A comment from
Telenor R&D N 4/2005 - 3
Report from IETF meeting attendance 2004
Nico Williams raised many eyebrows. He made an apology for voting against a security
related mechanism presented in a BOF at IETF60 in San Diego, a mechanism that was
discarded in the voting at the BOF. He hadn't understood the full potential of this
mechanism and appealed to reconsider this mechanism once more. Someone from IESG
told that there would probably be another BOF in a future IETF meeting on this theme.
IETF 60:
IETF Business Meeting (Marius Clemetsen):
IETF minutes: http://ietf.org/proceedings/04aug/981.htm
IETF chair Harald Alvestrand provided a brief status on number of attendees (1551), and
countries represented (40), among other things. There has recently been a slight increase in
number of attendees.
Jim Martins gave an overview of the IETF 60 network (fixed and wireless access).
Phil Grose got the ISOC Jon Postel Award.
There was a status report from the RFC editor (ftp://ftp.rfc-editor.org/innotes/IETFreports/aug04-report.pdf).
New copyright/IPR (Intellectual Property Rights) rules have been put into practice, and
there are new IESG rules for approving independent submissions (draft-iesg-rfceddocuments-03.txt). An advisory group consisting of a group of "wise heads" has been
formed to improve the RFC editor function. RFC statistics were provided.
IANA report (ftp://ftp.rfc-editor.org/in-notes/IETFreports/aug04-report.pdf): Waiting times
for documents have been reduced a lot due to the work on improving the processes.
DNS glue has been added to Top Level Domains (TLD) for IPv6. Still need for Root, but
that's being worked on. This is regarded as a major step in getting IPv6 "off the ground".
IETF statement by Bob Kahn (http://www.ietf.org/proceedings/04aug/slides/plenaryw3.pdf). Bob Kahn was urging people in IETF to take the IETF challenges seriously to
ensure the future success of the IETF.
IESG operations (Allison Mankin, Bill Fenner): They are working on how to provide
statistics on drafts (like number of submissions and number of approved drafts between 2
consecutive meetings). They also presented statistics for working groups as a whole. See
slides http://www.ietf.org/proceedings/04aug/slides/plenaryw-4.pdf.
Update from the PROTO work: Task: To improve scalability, transparency and
effectiveness of IETF document flow (home page: http://www.mip4.org/proto/). Slides
(http://www.ietf.org/proceedings/04aug/slides/plenaryw-5.pdf).
Presentation: Who's in charge of the Internet (see http://ietf.org/proceedings/04aug/981.htm
for more details). One of the main points: Many countries thinks that UN should be "in
charge" of the Internet. US and most developed countries says ...leave as is.
IAMB Chair report (http://www.ietf.org/proceedings/04aug/slides/plenaryw-7.pdf). They
plan a messaging workshop in September/October. Most recent published document is on
research funding. They are working on a liaison mechanics draft.
IRTF Chair report (http://www.ietf.org/proceedings/04aug/slides/plenaryw-8.pdf): Vern
Paxon presented the 13 groups of the IRTF.
4 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
IETF Planning Meeting (Geir Egeland):
The chair of the IRTF Anti Spam WG gave a presentation with the title "Spam is bad." The
presentation gave a broad picture of some of the issues one is facing in the fight against
spam, and how the WG is focusing its work.
There was a presentation of some of the results and recommendations from an IAB
workshop in 1997, which resulted in RFC2316. The conclusion was that what is described
in RFC2316 is now common knowledge and that areas where security is still lacking are
P2P, multi party protocols and DDoS.
The IETC chair presented the new IETF Mission Statement, which is now approved by the
IETF. He reported that the throughput of draft/RFCs in the IESG has increased, which
indicated that the IESG is working more effective. WGs that will focus on improving the
IETF has been started:
•
ICAR (Improved Cross-Area Review)
•
NEWTRK (New IETF Standards Track Discussion)
•
PROTO (Process and Tools, http://psg.com/~mrw/PROTO-Team)
•
EDU (http://edu.ietf.org/)
IETF 59:
IAB (Paal Engelstad):
IAB Plenary report: Leslie Daiglie presented the work status of IAB
IRTF status report:
He presented the research groups that have been active: AAAarch, Anti-Spam, Cryptoforum, Delay-Tolerant Networking, end-to-end (Distributed Denial of Service - DDoS resistance, etc), Internet Measurements, IP Mobility Optimizations, Network Management,
Peer-to-peer, Services Management, Routing (i.e. Interdomain Routing). Some of the HIP
(Host Identity Protocol) WG work might also be addressed by IRTF.
IESG (Paal Engelstad):
Host presentation: Most Koreans are not using ADSL, they use VDSL instead and have
25-50 Mbps to the home. The use of Internet Cafes, gaming and content is very popular. 1,5
Mbps phones are available.
Here, they want to make Korea the first big market for IPv6.
Nomcom presentation: Nomcom has selected 5 new IESG (Internet Engineering Steering
Group) members, and 6 new IAB (Internet Architecture Board) members.
RFC editor: New elements introduced into the RFC format (Intellectual Property Rights section, etc.) The editor queue is building up, so they are planning to increase the staff.
IESG Operations: Document status presented. This triggered a lot of discussion about the
document process of IETF and IESG in particular. (See discussions at a number of previous
IETF meetings. I will not repeat that discussion again!). However, here are some of the
comments
Telenor R&D N 4/2005 - 5
Report from IETF meeting attendance 2004
•
Comment: Examples of The PROTO experiment is going forward. But let us not be
too perfect about Proposed Standard.
o
•
Answer: There is not much perfectionism her. We could de-centralize
review.
Comment: The performance of the document process has really not improved
significantly
IESG Plenary session:
•
•
One questioned the consensus principle
o
It was great support for the consensus model.
o
Yakov Rekhter pointed out that the consensus model only works on the
WG level, but it stops when it comes up to the IESG level.
Is NomCom (Nominations Committee) effective?
o
•
4/5 thinks it works fine.
Bob Morgan: RFC2119 should it be changed.
o
Pekka Savola: Also use in operational advice might be troublesome. The
keywords are introduced to ensure interoperability of standards.
IETF Planning Meeting (Frode Kileng):
The Thursday meeting had three items on the agenda: Besides presentations and
discussions about political issues (IETF mission statement and the restructuring of IETF)
the plenary session included an invitation to start thinking about the concept of splitting
identifiers and locators in the Internet, instead of the current practice where the IP address
is both a locator and an identifier.
Eric Nordmark presented the concept of a splitting of identifiers and locators in the Internet.
This issue keeps coming up from several places, for instance in Multihoming and Mobility
related areas. The key question raised was if it's is a good idea to split locators and
identifiers. The presentation intended to be an invitation to start thinking about the concept
and possible solutions.
A split of locator/identifier is not just a routing problem. It also has to be solved in the
application layer since TCP for instance can't keep a session during an address change. The
idea is to keep the IP-address as a locator but to add an indirection layer, i.e. a "location
layer" named "Shim Layer", to do the mapping between the identifier and locator. A "Shim
Layer" would be an application layer transparent for most applications. It would also
require protocols to manage the mapping.
What should the ID be and how should it be allocated? An automatic allocated ID or
through a managed hierarchy? Should this include a new namespace? I that case it must be
a hierarchical namespace to be scalable to the whole Internet. Could this be mapped
through FQDN (DNS Fully Qualified Domain Name)?
There are a lot of issues related to the locators/identifiers split: scalability, failure detection
and management and a lot of difficult issues related to security.
6 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
A lot of issues were raised during the discussion. Not all supported the idea of introducing
this concept. Others were pessimistic, and didn't think it would be possible to find a
solution to all the problems involved.
Harald Alvestrand held an introduction to "Changing the way the IETF Works". Several
problems identified with the way IETF currently works have been described in draft-ietfproblem-issues (also see http://www.ietf.org/u/ietfchair/change-status.html). IETF has
initiated several steps to improve how the organization works, including the initiation of
ICAR (Improved Cross-Area Review), PROTO and NEWTRK. ICAR is a newly founded
WG that will work out mechanisms to improve the cross-functional review of work within
IETF (http://www.ietf.org/html.charters/icar-charter.html). PROTO is currently a "team"
(to become a WG?) that will look at tools that will improve the workflow for documents
passed between WGs and the IESG. The goal of the NEWTRK (New IETF Standards
Track Discussion) WG is to revise the IETF standards track including clearing up in the
confusion about PS, DS, use of the RFC label, etc. The NEWTRK WG meeting at this
IETF meeting suggested introducing WG status snapshots to separate status info from
technical specifications. The current proposals for the IETF restructuring process aims first
at creating structures to make things work, and later on to discuss the formal roles.
Telenor R&D N 4/2005 - 7
Report from IETF meeting attendance 2004
3 Reports from selected IETF working groups
3.1
Authentication in access networks
3.1.1 EAP (Extensible Authentication Protocol)
IETF 59 (Paal Engelstad):
2284bis has been approved as an RFC!
The Network Selection problem draft will be updated, but uncertain if this will be sent for
RFC.
Pasi Eronen discussed the remaining issues on the EAP State machine to resolve pending
issues. He claimed that all issues were resolved and fixed.
Pasi Eronen presented the keying issues. The draft has not been updated since IETF58.
Some issues include:
•
The "lying NAS (Network Access Server) problem": This seems not a pressing
problem. EAP channel binding might be the solution.
•
How to derive additional keys for EMSK, e.g. use IKEv2 (Internet Key Exchange
v2) PRF with HMAC-SHA1. Must use the same PRF to get independent keys (i.e.
AAA-key = PRF(....)) (AAA = Authentication, Authorization and Accounting)
Farid Adrangi presented the compound authentication binding problem draft.
The questions he needed to clarify were:
•
Compound Binding MAC (Medium Access Control) Key = EMSK
•
Compound Session Key = MSK
Comment by Jari Arkko: This binding problem appears many places (e.g. IKEv2). Does
this draft conform to other efforts, such as IKEv2?
Comment: Glen Zorn pointed out that the draft does not solve anything, since you can
always find other ways. It assumes that you can negotiate down to a simple authentication
method. But it does not solve any problem. It improves security, though, so it is not totally
useless.
Jari Arkko presented the Network Selection Problem
There are multiple problems:
1. Access Network Discovery
2. Identifier Selection
3. Selection of roaming intermediaries and
4. Payload Routing
and multiple activities:
8 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
•
Discovery
•
Decision
•
Indicating the selected network (can go in any direction)
Recommendations: Three first problems need new solutions. Most interest in Problem 1
and 3.
3GPPP: Problem 3 is relevant and requires an IETF solution. Uses L2 mechanism for
problem 1.
IEEE: Are they interested in more that problem 1? Problem 1 belongs to link-layer!
802.21: This work is relevant for their work.
Jari also detailed approaches for Problem 3
There are many possible solutions including database solutions and dynamic
discovery. Co-existing solutions are also possible.
The problem might also be solved on layer 2.
Comments by Glen Zorn: Why cannot AAA packets be routed over any
intermediate network? The operator's requirement here seems absolutely
meaningless.
Farid Adrangi presented his network selection solution draft:
•
3 cases: Recognized SSID (Service Set ID) of own operator, recognized SSID of
operator with known roaming relationship, and unrecognized SSID.
•
3GPP is only considering 1 level of intermediate networks, i.e. not a chain of
intermediate networks
3GPP: Solution to Access Network Selection and Mediating Network Selection:
•
Unrecognized SSID solution: Associate with each SSID and perform mediating
network discovery with the available SSIDs until and SSID with direct HSN has
been found. If not, the client chooses one of the intermediate networks based on the
discovered list of intermediate networks.
•
Use EAP-identity-request to deliver information.
•
The draft will be published as an Informational RFC as a short-term solution.
Method updates:
•
Have many methods, but few in the form of RFCs. New proposed methods was
presented:
•
A new method "EAP Bluetooth extension" was proposed and presented. All
Bluetooth keys are derived from shared pin code on devices.
o
I.e. we need infrastructure-based method using EAP.
o
Approach EAP-over-EAP-TLS (Transport Layer Security). Run E22 or E3
Bluetooth method in the inner EAP
o
Draft sent to Bluetooth SDO for comments
Telenor R&D N 4/2005 - 9
Report from IETF meeting attendance 2004
o
Backend changes are to be defined.
•
Another method for EAP-PSK (Pre-Shared Key) was also presented
•
"EAP-only" authentication for IKEv2 without the public key certificates that
IKEv2 requires
o
Could be used for e.g. EAP-AKA (Authentication & Key Agreement)
where you do not have certificates
o
Could use GSS (= Generic Security Service) EAP method instead of KINK
(Kerberized INternet Keying)?
3.1.2 PANA (Protocol for carrying Authentication for Network Access)
IETF 61 (Paal Engelstad):
Chairs: Patil B. and Alper Y.
The PANA meeting was very technical in nature, and the main purpose was to clarify
technical issues in order to be able to move forward. The WG has received much feedback
on the PANA documents and the WG meeting was therefore mainly addressing these
technical issues:
•
The technical issues for the PANA framework were clarified. The main questions
answered were: "How is PMK for each AP obtained by PaC?" and "How can PAA
install filtering rules for PaC to EP?" The proposed solutions were presented.
•
A lot of minor "details" for the PANA protocol was clarified at the meeting.
Network selection is one of the major issues triggering discussion. It intersects with
the network selection work undertaken in the EAP WG.
•
The open issues related to the use of PANA to enable IPSec based Access Control
relates to timeouts (e.g. what happens if PANA session lifetime is greater than
AAA-key lifetime, if the IPSec SA expires, or what about the lifetime of IKE PSK)
•
There were only minor changes to the work on using SNMP for the PAA-2-EP
interface.
•
The use of the Context Transfer Protocol (CTP) for PANA was presented. The
major issue for PANA is that PAA is not necessarily an Access Router, as required
by CTP. CTAR is also mandatory for CTP, and that is not necessarily ideal for
PANA. It was decided that since CTP is experimental, it is better to change CTP,
since there are people that wants to implement it for PANA.
IETF 59 (Paal Engelstad):
Open issues on PANA base specification was:
•
A new Internet draft on PANA framework was presented.
•
PANA runs between PaC (Pana Client) and PAA (Pana Authentication Agent),
while IKE runs to the EP (Enforcement Point). PAA use RADIUS/ DIAMETER
10 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
(or an API in case of co-location) between PAA and AS (Authentication Server).
PAA and EP may use SNMP to communicate (or an API if they are co-located).
•
EP is only needed if no secure channel is present when PANA is run, and if there
are no lower layer mechanisms (e.g. WPA-PSK i.e. WPA with Pre-Shared Key)
•
One distinguishes between Pre-PANA vs. Post PANA addresses. The former use
any common mechanism. The latter is optionally configured after PANA if IPSec is
used or if the Pre-PANA address is link-local. Here, if the IPv4 address is used it
must replace the Pre-PANA address because IPv4 cannot deal with multiple
addresses. The Post-PANA address can be configured by IKEv2 (Internet Key
Exchange v2) or by running DHCP (Dynamic Host Configuration Protocol) over
IPSec (RFC 3456).
•
Network/ISP Discovery and Selection. Traditionally based on NAI (Network
Access Identifier), port-number or L2 address based. Alternatively, PAA may
advertise the ISPs and the PaC explicitly picks one. This has been discussed on the
EAP mailing list, as well.
•
DSL: Here ISP selection can be done as follows:
•
o
It can be done as part of DHCP or as an attribute of the DSL access line, or
o
as part of PANA authentication.
WLAN
o
Either use IPSec, i.e. a EP is needed, or
o
Use WPA-PSK where PAA does the filtering.
It seems like the draft clarifies a number of questions related with PANA. Whether the draft
should become a working group item or not will be discussed on the mailing list.
Open issues with the PANA protocol and PAA-EP interactions (using SNMP) were
discussed.
Telenor R&D N 4/2005 - 11
Report from IETF meeting attendance 2004
3.2
IP version 6
The IPv6 working group has in 2004 more or less been working on updates on former
RFCs. These updates are required due to recent changes to the IPv6 protocol. The IPv6
standardization is however coming to an end, and if no major work items come up, the IPv6
working group will be closing in April 2005.
In 2004 the Multi6 WG formed a design team that merged 6 different drafts/suggestions.
This was decided at an interim meeting where there was consensus to continue working on
Wedge 3.5/Fat IP layer. At the November meeting, the design team presented their solution.
This work will be sent to the IESG in January 2005 and after that the group will either recharter or shut down.
The chairs are planning to spin off a separate working group to develop the actual protocols
for the solution that the design team has outlined. The reason for this is the same as the
reason for the tunnel-autoconfiguration spin-off in the V6OPS WG; working groups in the
operational area will primarily focus on operational issues, and not on protocol
development.
The V6OPS working group has for the last 2 years been working on scenario description
and analysis documents. All work on migration mechanisms and tools has been halted until
the scenario work is finished, which has been a topic for much controversy in the group.
This year the Operation and management Area Director has clearly indicated that this work
now must finished and a set of migration mechanisms must be recommended. The
enterprise analysis, however, is still not finalized.
There has been a lot of concern from vendors that while the working group is analyzing
scenarios, operators and companies are deploying IPv6and migration mechanisms. A
mechanism that is often used is tunneling. The chairs have therefore proposed to spin off a
new working group to develop a solution for tunnel end-point discovery and automatic
configuration. This was discussed in length, and it was a general consensus that this is a
good idea. The main idea is to leave the protocol development to a special WG, so that
V6OPS can focus on operational issues.
3.2.1 IPv6 (IP Version 6 Working Group)
IETF 61 (Frode Kileng):
Suresh Krishnan presented the progress on the "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6" (draft-ietf-ipv6-privacy-addrs-v2-01.txt) draft. Main changes in
the new version includes disabling the temporary addresses as default, DAD to be run on all
addresses not just per interface ID, and that multiple temporary interface identifiers are
allowed for multiple prefixes. Bob Hinden commented that implementations based on the
old spec are incompatible with the new. In a discussion about handling of address lifetime,
Tony Hain felt that this should be done per prefix, but Krishnan thought this should be done
globally.
Varada presented the status of "IP Version 6 over PPP" (draft-ietf-ipv6-over-ppp-v2-01.txt)
draft and informed that this draft is in "last call".
Jinmei presented status on "IPv6 Stateless Address Autoconfiguration" (draft-ietf-ipv6rfc2462bis-06.txt). The AD raised two major issues with the draft after it was submitted to
IESG September 2004. The first issue was related to the M/O flag behavior
(M=Managed=DHCPv6, O=Other=Stateless autoconfiguration) and the second one related
to the use of "stateful configuration" vs. DHCPv6. The detailed resolutions will be
12 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
presented to the mailing list, the draft will be revised based on the comments and the
document will proceed to "last call".
The AD comments after the IESG submittal of "Default Router Preferences and MoreSpecific Routes" (draft-ietf-ipv6-router-selection-06.txt) was also presented. The new
version (06) addresses all issues but one - the use of a default route that is not longer a
default. There exists a strategy for explicit deletion that requires no change. An alternative
using implicit deletion is problematic due to the increased complexity in nodes.
Erik Nordmark gave an update of the status of "Site Multihoming in IPv6" (multi6) WG.
I-D's on "practical questions around multi6 has been through last call and will be submitted
to IESG in January 2005. The WG is working on identifying proposals for further
development that will result in a WG recharter. A multi6 design team (DT) was formed at
IETF60 to look for an approach for layer 3 (L3) shim approach. 5 I-D's has been delivered
(-multi6dt-). A new and separate WG (in the Internet area) will likely work on specifying
the protocol. Some of their design goals are: minimal/no additional dependency on DNS,
that would make application referrals to work, good enough security, "thinking about
privacy", avoiding hard coding of /64-bit boundaries. The L3-shim layer will be placed
between IP endpoint and routing sub-layers (below fragmentation and IPSec) and will
provide "service" to all transport protocols. A new identification name space will be needed
(AAAA-recs still the same) where applications/transports use this new upper-layer IDs. The
shim-layer will switch locators on connection failure. Hash-based addresses will be used to
prevent redirection attacks.
Matsumoto presented the status of the draft "Source Address Selection Policy Distribution
for Multihoming" (draft-arifumi-multi6-sas-policy-dist-00.txt) (Intended for
"Informational"). Two problematic cases were identified resulting in traffic stopped by
ingress filtering and "wrong source address". Their approach is to create a mechanism for
distributing source address selection policy. RFC 3484 defines an address selection method
so this new mechanism will be able to distribute the policy to the nodes. Such a mechanism
will be important in un-managed networks in particular. The proposal is based on DHCPPD (instead of RIPng or OSPF) where the actual information doesn't differ but the use of
this is different than PD. David Thaler said that there's no good example that will justify
such a new mechanism. Several others said that it's necessary to have a mechanism that
makes it possible to enforce a policy from top-to-bottom.
Anycast was another item on the agenda. There seemed to be an agreement at the meeting
to initiate an "IETF Anycast WG".
IETF 59 (Paal Engelstad and Frode Kileng):
Hesham Soliam presented the 2461bis, i.e. the update of RFC 2461 "Neighbor Discovery
for IP Version 6". The update is due to several issues discovered in the 2461: 5 Issues
related to mobility (unresolved), 1 issue related to security (mostly solved) and 9 Neighbor
Discovery issues (2 still unresolved). The delay requirements to RA (Router
Advertisement) and RS (Router Solicitation) are targeted on booting, and should probably
be relaxed in case of mobility. DNA WG (Detecting Network Attachment) works on related
issues. IPSec should be replaced by SEND (Securing Neighbor Discovery), and it was
discussed if SEND should be MAY, SHOULD or MUST. Nordmark was concerned that
SEND is not yet PS (Proposed Standard) while 2461bis goes for DS (Draft Standard).
Kempf noted that this problem is part of a broader issue that should probably be addressed
by the Standards Track Working Group/BOF. Pekka Savola think it should be up to
implementers to use SEND if they need it. SEND might not be required with link-layer
security.
Telenor R&D N 4/2005 - 13
Report from IETF meeting attendance 2004
Tatuya Jinmei presented 2462bis, i.e. update of RFC 2462 " IPv6 Stateless Address Auto
configuration". There where 21 issues identifies with 2462 where currently 2462bis
resolves 14, solution to 2 issues needs confirmation and 5 issues are still under discussion.
There's a problem that a draft standard like 2462bis references DHCPv6 which is a
Proposed Standard and that such normative reference is not allowed in a draft standard. The
2462bis draft is expected to reach a final revision in the end of March 2004 before its sent
to a WG last call.
Updates on ICMPv6 (draft-ietf-ipngwg-icmp-v3-03.txt) were presented by Bob Hinden.
Besides the technical issues that the draft addresses, there are open issues regarding
procedures for assignment of ICMPv6 message codes form IANA. The challenge is to
conserve message ID space. A procedure where suggested by Hinden where codes
originated from the IETF will be requested from IANA based on WG consensus and AD
approval. Those codes are reclaimable bye IETF. Message codes originating from outside
IETF should be sent to IETF for review. There where a discussion if the draft tries to
redefine IANA assignment rules. The text of the draft will be updated and sent to a last call
in the WG.
Jun-Ichiro presented the draft "Multi-protocol getnameinfo" (draft-itojun-ipv6getnameinfo-multiproto-01.txt). The current getnameinfo() API (for reverse name lookup)
only supports TCP and UDP and this limitation is not feasible for a generic transport layer
independent API. New protocols need to be supported and the draft describes a
multiprotocol supported version of getnameinfo(). A clever solution with bit-masks, where
the binary value of the mask equals the current mapping for TCP and UDP, i.e. that
maintains binary and source compatibility with current applications. The discussion of
accepting this draft as a WG work item was directed to the WG mailing list. The author
wants do collect input to the draft and forward it to "the POSIX people". Afterwards, the
intention is to publish the draft as an informational RFC.
Bob Hinden presented an update of the WG Charter. The new charter includes work items
on Duplicate Address Detection (DAD), update on the IPv6 address architecture and on
IPv6 flow-label usage. The latter was questioned by Pekka Savola who stated that the flowlabel issues belong in the diffserv WG.
Other presentations:
•
Thaler presented a draft on Load Sharing.
•
Moore and Park presented their drafts on optimistic DAD (Duplicate Address
Detection). The idea is to optimistically start using an address. It remains tentative
for a while, where failures will be detected. The WG was in favor of adopting
Moore's document to optimize performance. Koodli pointed out that this might be
important for real-time applications that may not wait for DAD to complete before
using the address.
3.2.2 Multi6 (Site Multihoming in IPv6)
IETF 61 (Paal Engelstad):
Chairs: Kurt Lindquist and Brian Carpenter
First session (the second session not followed due to conflict with other WG meetings).
14 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
The design team is about to finish their work. The major important issue on this meeting
was therefore presentation of the outcome of their work. The work resulted in a number of
IDs:
•
Multihoming L3 Shim Approach (draft-nordmark-multi6dt-shim-00.txt)
•
Hash Based Addresses (HBA) (draft-bagnulo-multi6dt-hba-00.txt
•
Functional decomposition of the M6 protocol (draft-bagnulo-multi6dt-functionaldec-00.txt)
•
Failure Detection and Locator Selection in Multi6 (draft-arkko-multi6dt-failuredetection-00.txt
•
Multi6 Application Referral (draft-nordmark-multi6dt-refer-00.txt)
Erik Nordmark first provided an update on the background of the design team (DT) and its
work, assumptions made and so forth. Then each draft was presented:
•
The idea behind the shim approach is to introduce a Multi6 shim layer above IP
routing sub-layer and below the IP endpoint sub-layer (for fragmentation, IP Sec,
etc...).
•
The hash-based addresses resemble the use of GCA, however, using hashing on all
the available prefixes instead of using certificates.
•
The functional decomposition included a 4-way handshake to establish multi6 state.
•
For the failure detection and locator selection work one is trying to identify
mechanisms to detect lack of one-way or two-way reachability, and a mechanism to
select alternative addresses to be used.
The application referral draft was postponed for discussion on the next multi6 session. In
this session there will also be a final discussion on the work of the design team.
"The chairs are planning to spin off a separate working group to develop the actual
protocols for the solution that the design team has outlined. The reason for this is the same
as the reason for the tunnel-autoconfiguration spin-off in the V6OPS WG; working groups
in the operational area will primarily focus on operational issues, and not on protocol
development. The future of the Multi6 WG is still uncertain, and the chairs have indicated
that the Multi6 WG might be shut down, since the major mission of the WG is now
accomplished."
IETF 60 (Geir Egeland):
The WG just recently formed a design team that will try to merge 6 different
drafts/suggestions. This was decided at an interim meeting where there was consensus to
continue working on Wedge 3.5/Fat IP layer. One should consider changing the name to
either Wedge 3.4 or Wedge 3.6, since a solution must be related to either the transport layer
or the IP layer.
3.2.3 V6ops (IPv6 Operations)
Telenor R&D N 4/2005 - 15
Report from IETF meeting attendance 2004
IETF 61 (Paal Engelstad):
Chairs: Pekka Savola and Jonne Soininen
The WG has jumped through the hoop for two years with analysis work. It was a general
consensus (supported by the AD) that this period of time is now over and it is time to move
on. The enterprise analysis, however, is still not finalized. Therefore, Jim Bound started the
meeting by presenting the status of the document. Teredo, ISATAP and DSTM is what
enterprises are asking for, while 6to4 will probably never be used. (Brian C. commented
that 6to4 was designed for nothing more than small in-the-home experimentation with IPv6,
and that it is still used for what it was designed for). At the same time, tunnel end-points are
popping up everywhere.
The chairs proposed to spin off a new working group to develop a solution for tunnel endpoint discovery and automatic configuration. This was discussed in length, and it was a
general consensus that this is a good idea. The main idea is to leave the protocol
development to a special WG, so that V6OPS can focus on operational issues.
Jim Bound commented that the work on transition mechanisms was stopped during the
analysis period, and he was concerned that there is little focus on continuing the work on
transition mechanisms. By the same token, Hesham Soliman was concerned that the
mobility issues related to transition was not properly addressed in any group. In response,
Jonne Soininen asked if V6OPS should operate as a gatekeeper for spinning off new
transition-related working groups, but the AD responded that anyone is free to set up a BOF
independent of the V6OPS WG.
Since it was consensus to form a new WG, the presentations on the agenda about automatic
tunneling were skipped. Instead, the meeting moved on to other important issues:
IPv6 Network Architecture Protection (draft-vandevelde-v6ops-nap-00.txt) was presented.
Although there are obvious disadvantages of using NATs, there are also advantages. This
draft points out these advantages, and indicate how the demand for these advantages can be
addressed by IPv6 mechanisms. The goal with the presentation was to introduce and start
the discussion about IPv4 NAT alternatives in IPv6.
Davies presented reason to Deprecate NAT-PT (draft-aoun-v6ops-natpt-deprecate-00.txt),
and what to do with the NAT-PT draft was discussed. Someone pointed out the explicit
need for IPv4-to-IPv6 translation. However, Christian Huitema argued that the status of the
RFC should be moved to Experimental (not historical!) as soon as possible.
Popoviciu presented ISP IPv6 Deployment Scenarios in Broadband Access Networks
(draft-asadullah-v6ops-bb-deployment-scenarios-01.txt) and Tatuya presented a new WIDE
project called "IPv6 Fix". The project wants to solve barriers to IPv6 transition, and Tatuya
informed about these activities.
IETF 60 (Geir Egeland):
The scenario and analysis work is almost finished and there has been indicated from the
Area Director that the WG must recommend which migration mechanisms that should be
standardized. The OPS area does not produce protocols, so any new mechanism will not be
developed by the v6ops WG. The IESG will decide in which WG such new mechanisms
will be placed or whether a new WG should be formed.
The v6ops chair has recommended a set of mechanisms for the different scenarios. This has
been topic for much discussion on the mailing list recently. Much of the discussion is
whether ISATAP and DSTM should be a part of the recommended set.
The scenario and analysis work must be finished within the next 3 weeks, which puts
pressure on the enterprise work.
16 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
Some people in the group expressed a concern that the v6ops WG would be closed or that i
would evolve to a pure "tunneling" WG.
IETF 59 (Frode Kileng):
The scenarios documents that were important work items last year in v6ops are all in its
finishing stages, i.e.. are being sent to WG last call or has already gone though that and are
being forwarded to IESG. Security analysis of transition mechanisms and work on security
models are currently other important work items.
Pekka Savola presented issues with related to IPv6 in MPLS Networks, issues that are
unresolved after the last call of ” Scenarios and Analysis for Introducing IPv6 into ISP
Networks” (draft-ietf-v6ops-isp-scenarios-analysis-01.txt). IPv6 in MPLS networks are the
biggest unresolved issue in the ISP analysis and Pekka suggested 4 solutions on how to
introduce IPv6 in MPLS networks:
1.
Require native IPv6 support in the MPLS network
2.
Require support for IPv6 LSPs
3.
Use of IPv6 in IPv4 tunneling
4. Using an automatic tunneling mechanism enabling the set up of v6-in-v4 tunnels
Attendees raised hands and showed interests in an automatic tunneling solution based on
BGP tunneling or similar for enabling IPv6 in MPLS. There may be a problem with BGP
tunneling since Cisco has claimed IPR on 6PE, which is a Cisco marketing name for BPG
tunneling.
Pekka Savola presented the concept "Zero-configured Tunneling “ vs. "opportunistic
tunneling". Opportunistic tunneling, or ”ad hoc tunneling”, is a technique that is
applicable if the ISP doesn’t support IPv6 or tunneling services. I.e. the network lacks
support for migration mechanisms so users that need to communicate have to configure the
tunnels manually on demand. This is also tagged as a ”vendor driven” approach where
application vendors creates applications with “shiny” new functionality requiring IPv6. ” In
Zero-configured tunneling, tunnels are automatically configured without user interaction,
i.e. ”plug-and-play tunneling”. Many attendees clearly had a hard time understanding the
concept and the differences between them, even after a asking for a final consensus for
adding this as a WG work item! Nobody voted against taking on ”zero configured
tunneling” as a work item and only a few hands was raised against doing the same for
”opportunistic tunneling”.
Pekka Savola presented an introduction to an analysis of tunneling scenarios
(http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/scenarios-analysis.pdf). The analysis
is based on tunneling cases from the scenarios/analysis documents (unmanaged, ISP, 3GPP)
and will sort out the different mechanisms and try to find as few mechanisms (one or a few)
as possible that will suit a specific case, and to get consensus for this in the WG. The
intention is just to do an analysis of the current mechanisms, not develop new mechanisms.
It’s just to take one step back to do some analysis on the specific scenarios and to map
existing tunneling mechanisms directly to the scenarios. During the discussion, there where
many people questioning the goal of this work but Pekka pointed out that this is just an
analysis and that recommendations will come at a later point. There were also questions
about what should be done with the current work on tunneling mechanisms specification.
The answer was that there’s no problem continuing the work with such personal drafts in
parallel to this work. Pekka also asked several direct questions to the audience about this
work but the voting process didn’t complete and the discussion will continue on the mailing
lists. Anyway, there was a consensus to accept the document as a WG item. The
Telenor R&D N 4/2005 - 17
Report from IETF meeting attendance 2004
questioning about demanding Teredo for the unmanaged scenario showed no consensus
either way. There where also raised questions about voting for a mechanism with an
”unknown price tag” because of the IPR and licensing issues due to the ownership of
Teredo by Microsoft. There where also objections to the whole voting process since all the
implications of a vote was not known in front, and because the whole voting process was
somewhat difficult to follow...
Jordi Palet presented the draft ”IPv6 Distributed Security Requirements” (draft-paletv6ops-ipv6security-00.txt). Currently, network security, is based on firewalls on the border
to the external network. As long as computers stay behind the firewall computers are
secured. Jordi tells us that this model fails when considering nomadic users accessing the
network outside the protected area since infected computers may contaminate ”internal”
computers when taken back home. Jordi’s solution to this is to demand personal firewalls
that should do a run-time look-up of the security policy to the visited networks. The draft
sketches architecture of this model.
Satoshi Kondo gave a presentation of the “Quarantine Security Model” (draft-kondoquarantine-overview-00.txt, http://www.6bone.net/v6ops/minutes/IETF-59Seoul/quarantine-model.pdf). The motivation is the same as with Jordi’s “IPv6 Distributed
Security Requirements”, i.e. that security model using border firewalls is faulty. The
Quarantine model combines host-based security with network-based security and creates a
quarantine zone for newly attached nodes. If the security police of the attached host cannot
be verified, the host will continue to stay in the quarantine zone, a zone implemented as a
separate network segment. If the host security policy is verified, the host will be ”moved”
to network segment with ”higher trust level”. Several levels of security levels can be
supported in a network. The draft gives a high-level presentation of the concept and there’s
a need for going to the basics, describing protocols before the discussion can continue. The
author was encouraged to continue this work.
Carl Williams presented “IPv6 Mobility Scenarios/Requirements in 3GPP”
(http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/ipv6mobility-trans.pdf) describing
issues related to the transition of Mobile IPv4 to Mobile IPv6 (migration path) and issues
related to seamless roaming from IPv6 to Mobile IPv4 users. The latter is a complex issue
since there’s a need to balance complexity vs. performance. The answer was “yes” when
Williams asked if this issue belonged to the v6ops group since MIPv4 and MIPv6 is
different protocols and that migration issues is the responsibility of v6ops.
Pekka Savola gave an interesting presentation of statistics form a public available 6to4
relay that has been running since November 2001, the first statistics and analysis seen from
a public 6to4-relay (http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/6to4-stats.pdf.
Although the traffic has been very low, about 20-100 Kbit/s in average, the statistics shows
many peculiarities in which some have been identified to be a result of 6to4
implementation.
18 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
3.3
Mobility
3.3.1 Capwap (Control And Provisioning of Wireless Access Points)
IETF 61 (Paal Engelstad):
Chairs: M. Mani and D. Gellert
This was the first meeting as a WG, on earlier meetings it was a BOF. Some time was thus
spent on going through the new charter. The WG is now chartered to focus on the WLAN
controller backend architecture. The architectural scope is now limited to only Local MAC
and Split MAC. Protocol scope is limited to define the control plane, data forwarding and
extensibility to other IEEE 802 access technologies. For the latter part, the WG especially
has 802.16 (and possibly including 16e) in mind. The WG is still open for input on which
flavors of 802.16 are to be covered. In case of any conflicts on the objectives, the objectives
of pure 802.11 will have preference.
The WG is currently working on a set of objectives based on the architecture taxonomy
work (taxonomy draft, which completed IESG review in October and which is now refined
based on the IESG inputs). When this work is finished, the WG will evaluate a set of
candidate protocols as a basis for the CAPWAP protocol. Individuals are invited to submit
candidate protocol proposals to the WG within March 2005. There are currently two
submitted proposals. A CAPWAP Evaluation Draft will be produced, and used in the
selection process. The objectives draft is an important input as guidelines to the selection.
IETF requested the need for an AP Functional Description. As a result, the IEEE AP
Functions Ad-hoc committee was formed September 2004. The text will be included in
IEEE documents.
Two proposed objectives draft based on discussions on mailing list was presented. The
protocol should support both Local MAC and split MAC designs. A mixed deployment
should also be allowed. Support for logical networks is also an objective due to business
considerations (e.g. to reduce managing costs). Needless to say, CAPWAP must support
security and 802.11i. It is also crucial that the protocol supports multiple authentication
mechanisms. To facilitate deployment, automated mechanisms are encouraged. There
should also be support for status monitoring in the protocol. The WTP (WLAN
Termination Point) should both be manageable directly and via the AC. The CAPWAP
protocol also needs to coordinate performance (and thus enable QoS over the two
segments) and support 802.11e. It must also support fast handover capability. The drafts are
still not complete and need to address more aspects from the problem statement RFC. The
WG plans to merge the two drafts into one WG document. It was decided to pick one
individual from the author list of each of the two drafts as editors for the WG document.
IETF 59 (Paal Engelstad):
This WG will restrict itself to management, control, provision and deployment of APs
(Access Points), and not on mobility and security issues. It is also restricted to 802.11
(unless some people can justify also looking at other technologies too). The WG have a
limited scope and yet a limited timeframe. The plan is to conclude the WG or re-charter by
August 2004.
The problem statement has had only positive responses, and is going for Last Call.
Architecture Design Team formed of 11-12 members who will work hard on this problem
over the coming months. The work will result in functional description,
advantages/disadvantages, and threat analysis. There will be DT (Design Team) meetings
and a high level of interaction with the mailing list.
Telenor R&D N 4/2005 - 19
Report from IETF meeting attendance 2004
A question raised was: Why should this work be done by IETF?
What has happened since last IETF:
•
New focus on problem statement and architecture
•
Need good understanding of what is available amongst vendors.
•
The whole draft probably needs to be re-written.
What should the Architecture draft cover today:
Document how vendors implement
Standalone AP architecture
Variety of implementations of AP+AC (Access Control) architectures in the market
Pro and cons including security threats of each, functional interfaces of each
Tradeoff between interoperability and flexibility, will be a hard problem
Need to understand the landscape and achieve some compromises
Where are we today:
802.11 gives a loose architecture with station services, distribution services,
integration,...
Most vendors also provide AP load balancing, mobility support, network security,
RF (Radio Frequency) control & management
Today most APs are standalone / fat / self-contained
New trend is to put centralized AC in the back end, which yields better
management, and network wide visibility and control.
However there are no standard to map functions to WLAN functions to AP and
AC.
Variants: Fat AP (ARCH 0), Split AP (ARCH 1), Split MAC (ARCH 2), Antenna
AP (ARCH 3)
Clarification 1: Split AP, i.e. AP = MAC (Medium Access Control) and
AC = above
Clarification 2: Split MAC, i.e. AP = RT MAC and AC = NRT & above
There is a tradeoff, e.g. ARCH 3 may constrain the distance between AP and AC
802.11 IEEE IETF status (joint meetings):
•
Discussed
20 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
•
o
CAPWAP
o
RADIUS Extensions
o
EAP (Extensible Authentication Protocol) Network Discover
CAPWAP discussion
o
Several vendors want an IETF protocol that enables interoperability
IEEE 802.11 "owns" the definition of AP functionality
IETF defines protocols between network elements
CAPWAP Arch-draft issues:
Does not require data path to traverse AC
Is CAPWAP too narrowly focused on IEEE 802.11? Other technologies should
probably be addressed as a research effort in IRTF (Internet Research Task Force)
instead, and is not in the CAPWAP charter now.
CAPWAP is not about distributed routing
Capability negotiation to help interoperability
We still need to find a functional balance
The definitions of AV, AR and AC should be clearer and will be fixed in the draft.
APs and ACs must be identified by IDs that must be authenticated
The AP will be associated with only one AC at the same time (but they can be
authenticated with several ACs to enable fast failover).
CAPWAP Functional Classification
Split functionality is a major industry direction. Incompatible functional splits.
There is a lack of means to classify functionalities.
Must have a managed compatibility, i.e. enterprises must buy all equipment from
same vendor.
An AP associates with ANY compatible AC
Policy 1: APs negotiates functionality split with AC
Policy 2: AC supports all functionality not supported by the AP
Functions need to be grouped. Some functions can be divided, others cannot
3.3.2 DNA (Detecting Network Attachment)
IETF 61 (Paal Engelstad):
Chairs: Greg Daley and Pekka Nikander
Telenor R&D N 4/2005 - 21
Report from IETF meeting attendance 2004
The scope of link information is to provide link-layer status to IP to inform that a
reconfiguration is required, to provide useful information for subsequent update of the IP
configuration, and so forth. Technologies addressed for link events should include
GPRS/UMTS, CSMA 200 and 802.11. 802.16 link-layer triggers will wait until the
mobility specification of .16 is ready. 802.3 and 802.11 Ad Hoc Mode might also be
addressed eventually. The link information draft on GPRS/UMTS was discussed. The draft
seems to have a lot of shortcomings, and more people are required to work on it to get it
right.
The working group also wants to establish Best Current Practices for DNA. Two drafts are
proposed, draft-narayanan-dna-bcp-01.txt and draft-jinchoi-dna-cpl-01.txt. The drafts were
presented and discussed. In the first draft two DNA steps are recommended; validation of
current configuration (e.g. IP protocol version, presence of particular link, valid addresses
and routers supported etc.) and reachability detection (since bi-directional reachability with
current default router is crucial to continuing use of current configuration). The second
draft proposes the DNA solution to be based on 1) Link Identifier, 2) RA optimized for
DNA and 3) Quick delivery of an RA and sketches what rough shape DNA solution will
take. It also enumerates a few tasks to be worked on and issues to be resolved for efficient
DNA solution.
The chairs proposed to merge the efforts on BCP. It was also decided to split the merged
BCP efforts into two drafts; one BCP document for clients and one BCP document for
routers and networks.
It was proposed to consider a design team for the solution work, which can be based on the
drafts draft-jinchoi-dna-soln-frame-00.txt, draft-narayanan-dna-rrd-00.txt, draft-daley-dnadet-fastra-01.txt and draft-pentland-mobileip-linkid-03.txt. The current status of these drafts
was presented. They include fast RA using caching and a mechanism for defining and
conveying Link Identifiers.
The proposed solution framework was presented (supporting the second BCP draft
discussed above). The chairs found it useful and it was accepted as a WG document. It
should however adopt inputs from the other solutions documents. The document is also
useful as input to IPv6 working group (e.g. since it covers optimistic DAD) and might
guide the work undertaken in the IPv6 WG.
3.3.3 MANET (Mobile Ad-hoc Networks)
IETF 61 (Paal Engelstad):
Chairs: Joe Macker and Scott Corson
Agenda:
The MANET WG is in the process of re-chartering, and the meeting was open for inputs.
The group has produced four experimental routing protocols. Now there are 3 working
items proposed for the new charter:
1. Reactive routing protocol work item, to produce a protocol for standards track
2. Proactive routing protocol work item, to produce a protocol for standards track
3. Simplified Multicast Forwarding Protocol Work Item, to produce a protocol for
standards track
22 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
The charter will be posted on the list shortly. The ADs are afraid of expanding the scope of
MANET too much. Furthermore, MANET is within the routing area. However, there might
be openings for BOFs on multihop autoconfiguration issues.
Ad 1: Reactive routing protocol work item (Chakeres)
DyMO: Wants a simple method to create a route. It should be extensible, support IPv4 and
IPv6, etc...
The base spec will have a RREQ/RREP exchange with the destination only, without bidirectional links. During RREQ, each node appends its address, while the RREP reverses
the RREQ path.
Ad 2: Proactive routing protocol work item (Clausen)
There will be no IPR in the baseline specification. The spec will include gateway operation,
and it should also be extensible. (For both proactive and reactive protocols there is a tradeoff between what shall be included in the base spec and what shall be addressed as
extensions.) Local signaling will be used for bi-directionality tests and topology
maintenance. Global signaling is performed through optimized multicast. Furthermore,
partial topologies are used to reduce the number of MANET-wide multicasts. A design
team will be formed, and the work will be based on running code.
Ad 3: Simplified Multicast Forwarding Protocol work item
Will probably use something similar to MPR-F, and duplicate packet detection. The base
spec will be as simple as possible, and also extensible.
IETF 60 (Geir Egeland):
The WGs’ focus is to approve a new charter. The new charter was sent to the mailing list in
May and it states that the focus should be to work on wireless IP routing protocols. The
WG will no longer be working on autonomous MANETs and will instead concentrate on
MANETs that are a wireless extension to the fixed Internet. The WG has two standard
tracks:
•
MANET reactive Protocol (MRRP)
•
MANET Proactive Routing Protocol (MPRP)
The WG will also produce informational documents such as “How to do MANETs,”
typically:
•
Addressing/autoconfiguration
•
Discovery
•
Security
•
IPv4/IPv6 specifics
•
Applicability Docs.
•
Best Practice Docs.
Telenor R&D N 4/2005 - 23
Report from IETF meeting attendance 2004
The OSPF-MANET initiative is removed from the WG and will continue in the OSPF WG.
The work will be done in a newly formed design team. This protocol will not be a
replacement for the proactive protocols from the MANET WG.
IETF 59 (Paal Engelstad):
Requirements to IP Address Autoconfiguration were presented. Paal Engelstad commented
that we should not over-specify the requirements. Instead, we should start out with a simple
solution, such as the draft-perkins-manet-autoconf-01.txt. Furthermore, he remarked that
maintenance of upper layer sessions is probably not an item that this WG should do, as the
problem is of a more general nature and could just as well be addressed by other groups
(eg. zeroconf).
A scheme for external IP connectivity was presented. Paal Engelstad pointed out that using
default routes is not a good idea. Explicit tunneling to the gateways, is probably necessary.
Thomas Clausen said that he could not understand how this draft differs from the previous
work published by wakikawa (draft-wakikawa-manet-globalv6-01.txt).
Charlie Perkins presented a general mechanism for Multipoint Relay (MPR) based flooding
on MANET. The mechanism is targeted at all the four experimental routing protocols.
Thomas Clausen presented a draft on OSPF database synchronization. No comments, as
none had read the draft.
Tom Hendersen gave a brief overview of the work that has been done on OSPF extensions
for MANET. The problem is that OSPF does not have a suitable interface type for
MANET. Follow-up discussions are going on in OSPF WG. Fred Baker has published a
problem statement, and the area director suggested to use this as a basis for further work.
Fred said that they are building the protocol right now, independent on whether MANET
adopts the problem statement. Charlie Perkins said that the current charter does not assume
the use of OSPF.
Charlie Perkins requested an extension of the MANET charter. However, the area director
would like completion of the current charter before adding new items to the charter.
Koojana Kuladinithi presented some experimental performance evaluation of AODV (Adhoc On-demand Distance Vector routing). It was difficult to understand the conclusion of
the experiments.
3.3.4 MIP4 (Mobility for IPv4)
IETF 59 (Paal Engelstad):
The chairs presented the documents status.
Then a proposal for a fixed type-number for experimental extensions was discussed, but the
WG decided to drop to go further with the proposal.
A mechanism to compress the inner header of MIPv4 NAT traversal packets was proposed
and thus save 20 bytes. It was discussed if this issue is not an issue for ROHC (RObust
Header Compression), instead.
A mechanism was proposed for MTU (maximum Transfer Unit) discovery between HA
(Home Agent), FA (Foreign Agent) and MN (Mobile Node). The endpoints can then select
the right packet size. The problem of routers dropping large packets is most pressing on
24 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
ADSL links. The WG will check on the list if there is any interest in the WG to continue
working on this issue.
Perkins gave a short background on his draft on FA-Error-Codes. The new extension option
allows a foreign agent to supply an error code without disturbing the data supplied by the
Home Agent within the Registration Reply message. In this way, the mobile node can
verify that the Registration Reply message was generated by the Home Agent even when
the foreign agent is required by protocol to insert new status information into the
Registration Reply message. A question for the WG to adopt the draft will be sent to the list
as soon as the draft is published on the IETF draft directory. If OK, it will be sent for last
call.
3.3.5 MIP6 (Mobility for IPv6)
IETF 61 (Paal Engelstad):
Chairs: Basavaraj Patil and Gopal Dommety
This was mainly a working meeting going through many subjects without addressing any
major decisions.
Most important issue is that there seem to be a consensus on the mailing list to publish the
Auth-ID solution (draft-ietf-mipv6-auth-protocol-00.txt) as an alternative to using IPSec
between MN and HA. The alternatives were: To not publish at all, to publish along
standards track, or to publish as Informational or Experimental (e.g. as for several 3GPP
documents). Since the consensus was rather rough (with accusations of companies "packing
the room" with voters etc.), the question was raised again. It seems that few are in favor of
not publishing, while the majority prefers to publish as Informational. James Kempf, for
example, argued that there might be some interoperability problems by having two
mechanisms. Erik Normark commented security weaknesses in the draft (i.e. it assumes that
the HoT message is delivered over a secure network), and also argued for publication as
Informational. Due to time limitations, it might be published as Experimental first, and as
Informational later when the WG has had more time to review the mechanisms.
Apart from this issue, the main focus was on different aspects of bootstrapping:
•
Vijay Devarapalli presented the MIP6 Operation with IKEv2 and the revised IPSec
Architecture draft (draft-ietf-mip6-ikev2-ipsec-00.txt). The idea is to support
dynamic bootstrapping including IPSec, use of EAP and home address
configuration. The MAYs, SHOULDs and MUSTs of dynamic IKEv2-based
keying, configuration issues (including SDP selectors etc), EAP, and home address
configuration were also discussed.
•
Dupont presented how to use IPSec to protect signaling between MN and CN as an
alternative to return routability test (draft-dupont-mipv6-cn-ipsec-01.txt). It was
strong consensus to make this a WG item. He also presented state-cookie based
routing optimization. A state cookie, initiated by CN, is used in order to avoid easy
DoS attacks. It changes the MIPv6 space spec (unlike the earlier proposal by
Perkins), but the advantage is that the mechanism can be used by any upper layer
mechanism. Erik Nordmark remarked that the security of the scheme should be
scrutinized.
Telenor R&D N 4/2005 - 25
Report from IETF meeting attendance 2004
•
Gerardo Giaretta presented an AAA scheme as an alternative to using IKEv2 to
simplify the set-up of the SA: For Mobility Service Providers (MSP) the HA works
as a kind of NAS (although there is a separate NAS for authentication on the access
network). An AAA-HA protocol is needed to carry EAP between the "AAA-MSP
Server" and the HA. (Yegin Alper has proposed an alternative draft on this issue.)
In addition, exchange of accounting information and bootstrapping configuration
might also be required. He pointed out that even when IPSec is used for
authentication, it is not sufficient for the authorization of the MIPv6 service (draftgiaretta-mip6-authorization-eap-02.txt). Diameter, RADIUS and SNMPv3 are
some candidate protocols. MN-HA IPSec SA can be set up from the keying
material (Application Master Session Key) exported by the EAP method (draftgiaretta-mip6-amsk-00.txt). The WG decided to try to work out some requirement
as inputs to other WGs.
•
Junghoon Jee asked if it is appropriate to use PANA to deliver the bootstrapping
information (draft-jee-mip6-bootstrap-pana-00.txt and draft-tschofenig-mip6bootstrapping-pana-00.txt). Question was taken to the list.
•
Yoshihiro Ohba, on the other hand, proposed to use DHCP for Mobile IPv6
Bootstrapping Architecture (draft-ohba-mip6-boot-arch-dhcp-00).
•
Other things discussed: Bootstrap Control Function mechanism for Mobile IPv6
Bootstrap (draft-deng-mip6-bootstrap-bcf-00.txt); Precomputable Binding
Management Key Kbm for Mobile IPv6 (draft-ietf-mip6-precfgkbm-01.txt).
•
Thierry Ernst asked if there is support for multiple interfaces on a host (i.e. host
multi-homing) in MIP6. Kempf felt that it is too early to add such a complex issue
at this time. Furthermore, some parts of the problem/solution are not MIPv6
specific. Gab. M. suggested to include scenario with both IPv4 and IPv6 addresses.
Savola suggested forming a BOF that will include people from different groups.
The next step for the WG is to bring to closure on the authentication issue. The WG will
also look into transition problem statement. In addition a design team will be formed to
address the bootstrapping work.
IETF 60 (Geir Egeland):
The mobile IPv6 draft has reached RFC status. The GW is now working on issues
regarding authentication and AAA in connection with bootstrapping. There is a draft (draftietf-mip6-bootstrap-ps-00) that describes the problems and suggests a possible solution.
The WG will focus on working with a protocol for bootstrapping.
IETF 59 (Paal Engelstad):
The chairs (Basavaraj Patil, and Jari Arkko) presented the status of current drafts. Most
important, draft-ietf-mobileip-ipv6-24.txt was approved by IESG for proposed standard
spring/summer 2003, while draft-ietf-mobileip-mipv6-ha-ipsec-06.txt was approved a little
later. Both drafts have passed the IANA queue (3 months delay) and are now in the RFC
queue.
A connectathon has tested out MIP Advanced APIs, and no major problems where detected.
www.tahi.org now offers a free test-suite for MIPv6 that can be downloaded
26 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
James Kempf presented the bootstrapping issue. It comprises dynamic home agent
discovery and bootstrapping of a SA (Security Association) between HA (Home Agent)
and MN (Mobile Node). For the latter you may use AAA (Authentication, Authorization
and Accounting) extensions or IKEv2 (Internet Key Exchange v2). With IKEv1, on the
contrary, the MN must have a statically defined Home Address (although some IKEv1
implementations can handle a dynamic address). It was discussed to which extent
renumbering is a part of a bootstrapping mechanism. The challenges where presented.
Drafts to address the issue are on the way.
The problem-statement draft on HA reliability identifies HA failure, failure detection and
recovery as important issues. SA must be reestablished. Correct ordering and load
balancing is also relevant issues.
Hesham Soliman presented dual-stack mobility based on a problem-statement and a
solution draft. The solution draft proposes to use an IPv4 address as a CoA (Care of
Address) for MIPv6 and vice versa.
Franck Le presented how MIPv6 may face problem together with stateful firewalls (State
shut down on TCP FIN and timeouts).
•
If CN (Correspondent Node) is behind a firewall, the firewall will drop the HoTi
(HOme Test Initiation) and CoTi (Care-Of Test Initiation) messages.
•
If MN, on the contrary, is behind a FW, the FW will stop the HoT message because
the HoT is encrypted.
•
Even if RRT (Return Routability Test) succeeds the new packet from CN may be
dropped.
TCP SYN from HA to MN may be stopped by the firewall.
Mobile IP NAI (Network Access Identifier) extensions for mobile IPv6 were discussed.
The question is if the use of NAI should be allowed in MIPv6 instead of the current use of a
static address for HA assignments? James Kempf argued that this should be integrated as a
bootstrapping mechanism.
A problem statement for MIPv6 AAA was presented. It was pointed out that AAA for
network access is not the same as AAA for MIPv6. The latter is AAA to allow mobile users
to use MIPv6 services.
3.3.6 Mobike (IKEv2 Mobility and Multihoming)
IETF 61 (Paal Engelstad):
Chairs: Paul Hoffman and Yari Arrko.
Mobike has become a WG. Most of the meeting was dedicated to clarifying the scope of the
working group. Secondly, the chairs wanted to discuss what the design principles for
MOBIKE should be.
Since there have been a lot of questions related to multi-homing, address selection, and
failure detection/recovery, the meeting started with presentations that went through these
issues:
Telenor R&D N 4/2005 - 27
Report from IETF meeting attendance 2004
•
Multihoming: Must learn the peer's address (prior to failure) by means of the
MOBIKE protocol. As a design principle, it was proposed that the WG would only
focus on the bi-directional reachability case.
•
Addresses: Addresses come from (and are taken away from) other parts of the
stack. Thus, MOBIKE must believe information coming from other parts of the
stack. You have available addresses and locally operational addresses. However,
the latter is not sufficient since the path might be broken, thus the definition
"operational address pair" is introduced. As a design principle, it was pointed out
that both local and global connectivity must be addressed. A main principle is that
MOBIKE is for standardization for interoperability between the two peers and not
software design. Therefore, most internal communication within the stack is
outside of scope. For interoperability, MOBIKE will obviously need an IKEv2
message pair between the two peers (since both modifying ESP and introducing a
new protocol seem out of the question).
•
Failure detection: For failure detection, IKEv2 already has dead-peer-detection.
Additional methods might supplement.
The scope of MOBIKE was first discussed. Most important is that MOBIKE is not going to
solve mobility issues in general. The main issue is that if you lose connectivity, you do not
want to run IKEv2 from the start (involving user interaction with typing in passwords),
since you already have all keys installed. Instead, MOBIKE will be able to replace an
address that is not working, while maintaining the IKEv2 session. Understanding this small
problem that MOBIKE wants to address is crucial for the understanding of the scope of
MOBIKE.
Finally, questions concerning design principles for MOBIKE was raised related to the
presentation on Multihoming, Address selection and Failure detection/recovery (above).
IETF 59 (Paal Engelstad):
This was the first mobike meeting. Mobike will not replace work on IKEv2 (Internet Key
Exchange v2) in IPSec WG or mobility work in MIP4 WG (Mobility for IPv4) or MIP6
WG (Mobility for IPv6). Addresses can be changed with the use of IKEv2 (which is used
for example to establish a VPN tunnel to a Security Gateway). The protocol thus will allow
for mobility and multi-homing.
Francis Dupont presented his ideas on how addresses should be managed by means of
address sets. You have an initial exchange of an ordered list of addresses that is
authenticated. You may use return routability and you should be able to change address
anytime.
The WG is currently not yet addressing header compression.
Tero Kivinen presented a proposal for a Mobike Protocol. It tries to reuse as much of
IKEv2 as possible, but introduce a new notify payload for IPv4 and for IPv6 (and for the
zero address set, see below). IKEv2 dead-peer-detection is used for return routablitity.
Multihoming is done by starting with the most preferred address. If it does not work
anymore, use the next address on the address list. Return routability is done for each
address. The peer may also send a direct indication of change. That message is
authenticated. If the new address is not known in advance, the session is moved
immediately and the return routability test is started. Indication of change can also be
indirect, i.e. an ICMP host unreachable message is received, no packets are received, or the
other end starts using another address. He also proposed a zero address set where the peer
can notify that he will go away for a while.
28 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
Tero also presented design guidelines for the protocol to be developed. There are 2
scenarios; a roaming laptop and a multihomed SGW - Security Gateway (VPN Gateway).
You then want to change the IP address of the IKE and IPSec SAs (Security Associations)
without having to doing a re-key. Thus the protocol needs to notify the other end about IP
address list changes, so that IKE SA endpoint address can be changed. We must also switch
to a new address on the address list if the current address does not work. Return routabililty
is needed with indirect indication of change, because in this case the indication has not been
authenticated by IKE.
•
It was questioned if we actually need automatic switching or address lists. Without
automatic detection, the protocol is simpler. This issue should be discussed further
by the WG.
•
It was pointed out that NAT traversal is out of scope of this WG. The reason that
IKEv2 works over NATs, is that IP-addresses are never sent in the payload. Mobile
IP does the opposite, and will therefore not work across NATs. It would be nice if
mobike (v4) should allow for mobility between NATed sites. The NAT issue seems
complicated, and will probably need more work.
•
We need a way to ensure that Mobike and Mobile IP do not do the same thing.
Maybe a draft that tries to combine Mobile IP and IKEv2 would be needed.
The chairs (Jari Arkko and Paul Hoffman) solicited more individual submissions for
additional proposals.
3.3.7 Nemo (Network Mobility)
IETF 61 (Frode Kileng):
One of the main items on the agenda was a presentation and discussion about "Analysis of
Multihoming in Network Mobility Support" (draft-ietf-nemo-multihoming-issues-01.txt)
which analyze multihoming in the context of network mobility. The proposed taxonomy
and possible deployment scenarios was described. The presentation ended in a discussion
relating to the core problem definition. I.e. which problem we’re trying to solve and which
problems that should be addressed.
“Global HA to HA protocol” (Global Home Agent to Home Agent Protocol) (draft-thubertnemo-global-haha-00) was presented as an extension of Mobil IPv6 to support the mobility
of a Mobile Router, i.e. network mobility as needed for example in airplanes.
Most of the time in the meeting was used to present and discuss possible candidates for a
NEMO RO (Route Optimization) problem statement. The candidates/drafts was "NEMO
Route Optimization Problem Statement" (draft-clausen-nemo-ro-problem-statement-00.txt),
"NEMO RO Pb Statement, Requirements and Evaluation Considerations" (draft-zhaonemo-ro-ps-00.txt), "RO with Nested CNs" (draft-watari-nemo-nested-cn-00.txt) and
"Update of "Taxonomy of RO models in the NEMO context" (draft-thubert-nemo-rotaxonomy-03.txt). The chair asked whether one of the current drafts should be the basis for
a WG problem statement of NEMO Route Optimization, or if a new should be written
based on input from the candidates. One from the audience stated that we really need a new
one since all the candidates includes “solutions” and that it may exist other solutions than
the ones identified. Erik Nordmark supported this since a problem statement should not
include solutions. The discussion continues on the WG mailing list.
Telenor R&D N 4/2005 - 29
Report from IETF meeting attendance 2004
3.4
Routing
When it comes to multicast routing no new groups have started dedicated to this category,
and no group terminated. The work is currently carried out in:
•
magma (Multicast & Anycast Group Membership)
•
mboned (MBONE Deployment)
•
msec (Multicast Security)
•
pim (Protocol Independent Multicast)
•
rmt (Reliable Multicast Transport)
•
idmr (Inter-Domain Multicast Routing)
•
ssm (Source-Specific Multicast)
The 2 last groups have not had any meetings in 2004.
We have been following meetings in the mboned (working with multicast deployment
issues), rmt and pim groups. We have also followed the l3vpn (Layer 3 Virtual Private
Networks) group with particular emphasis on multicast in the context of layer 3 VPN.
An important obstacle for the deployment of multicast has always been the lack of support
of multicast in many network segments, which has required a manual setup of multicast
tunnels. We may now see a solution to this problem in the AMT (Automatic IP Multicast
Without Explicit Tunnels) draft presented to the MBONED WG.
3.4.1 L3VPN (Layer 3 Virtual Private Networks)
IETF 60 (Marius Clemetsen):
Requirements and framework specification is mostly done. The same goes for the security
framework, the specification of the (3) different VPN solutions, and accompanying MIBs.
Work is now progressing on multicast and IPv6.
See (http://www.ietf.org/proceedings/04aug/minutes/l3vpn.htm) for the IETF meeting
minutes.
The main topics of the meeting were multicast and IPv6 in Layer 3 VPNs. The meeting
started with agenda bashing, a quick presentation of the new approved charter that includes
multicast and IPv6, and a review of existing documents.
There are currently 2 proposed multicast solutions. The first proposal is "draft-rosen-vpnmulticast-07.txt" (proposed by Cisco), and the second is based on the previous version (06)
of the rosen draft, but implements only a subset of the draft (and is promoted by Juniper).
Eric Rosen presented " Base Specification for Multicast in BGP/MPLS VPNs" (draft-rosenvpn-multicast-07.txt) as a de facto standard, and promoted it as a working group item. He
pointed out a few unresolved issues – with proposed solutions: (see meeting minutes for
details).
•
General inter-provider solution
•
Non-congruent multicast topology
•
Auto discovery for PIM-SSM
•
Which PIM-variant to require
30 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
Rahul Aggarwal presented "Base Spec. for Multicast in BGP/MPLS VPNs" (draftraggarwa-l3vpn-2547-mvpn-00.txt). The motivation behind the draft is to document a
minimal set of procedures for interoperable MVPNs. He argued that PIM-SM must be used
(instead of PIM-SSM as promoted by Eric Rosen) in core to avoid state explosion, and
presented an example of a typical ISP setup yielding 1M states in the core routers. This
example was questioned by the audience, and a discussion is to be continued "on the list".
He promoted the draft as a working group item.
Rahul Aggarwal then presented the draft "Preserving BGP Next-Hops" (draft-raggarwabgp-nexthop-rewrite-00.txt). This draft specifies the use of 2547 inter-AS option B for
multicast VPNs.
There was a discussion on the use of PIM-SSM vs. PIM-SM in the core related to possible
scaling issues by using PIM-SSM in the core. Discussion on scaling issues was "taken to
the list".
Susheela Vaidya presented "Multicast MIB" (draft-svaidya-mcast-vpn-mib-00.txt). This
MIB is based on Rosen-draft, but also addresses the Aggarwal draft. The author argued that
the MIB is flexible and can easily cover both proposals. The discussion on this should be a
working group item was "taken to the list".
Jeremy DeClercq presented "IPv6" (draft-ietf-l3vpn-bgp-ipv6-03.txt) on behalf of Francois
Le Faucher. This is already a working group document. The draft specifies the
encapsulation of IPv6 datagrams from customer sites over an IPv4 or IPv6 backbone. The
draft is on hold waiting for the 2547bis. There were some potential issues that needed to be
sorted out on the mailing list before advancing the draft.
The last agenda item, "BGP-MPLS VPN extension for IPv4/IPv6 Hybrid Network" (draftdefeng-l3vpn-ipv4-ipv6-hybrid-00.txt) was not presented, as the author didn't get a Visa to
enter the US.
3.4.2 MBoneD (MBONE Deployment)
IETF 61 (Frode Kileng):
The mboned WG coordinates the deployment, engineering and operation of multicast
routing protocols and procedures on the global Internet. One of the biggest issues currently
is the IMDOC (Internet Multicast Documentation, Oversight, and Coordination) initiative
that addresses multicast deployment issues on a broad scale. There are also some important
unresolved issued related to multicast group control, inter-domain multicast and address
allocation.
Current status of some interesting active mbone drafts: The BCP draft (draft-ietf-mbonedssm232-08.txt) describing operational requirements of source specific multicast in the IPv4address range of 232/8 1 is finished and waiting in the RFC Editors queue. Also the draft
proposing a standard for embedding the Rendezvous Point (RP) in the IPv6 multicast
address is waiting in the RFC editors queue to be released as a PS. The draft describing
BCP of the deployment of the interdomain multicast source discovery protocol (MSDP) is
finished and in the editor queue.
Dave Thaler presented a draft of high Telenor relevance for improving content distribution
and streaming. The draft gives a solution to one of the main challenges in the deployment
of mbone in IPv4 for the last 10 years, a challenge we also now see in the IPv6 multicast
deployment. The draft (draft-ietf-mboned-auto-multicast) describes AMT (Automatic IP
Multicast Without Explicit Tunnels), a mechanism for automatic tunneling of multicast
Telenor R&D N 4/2005 - 31
Report from IETF meeting attendance 2004
traffic over network segments that doesn’t support native multicast. Thaler identifies
content providers and later the ISP as interested in deploying this. AMT uses a mechanism
similar to 6to4 and a 3-way handshake technique (AMT request, AMT IGMP query and
IGMP report) using hashing for security reasons. Action items for further work include
reserving necessary UDP ports by IANA. An experimental implementation of a FreeBSD
GW/Relay is available and is offered to providers for experimentation and testing. A voice
from the audience raised an objection to defining yet another tunneling mechanism
requiring new tunneling code to be written. Thaler said that the Teredo-solution is the basis
for this new mechanism and it wasn’t a complete new work. Scalability was another issue
where Pekka Savola said, based on their analysis of the FUNET 6to4 public relay, that
since state is not created for non-active users, there should not be any scalability problems
with AMT.
Thaler also presented the “Uni-Prefix-based IPv4 Multicast” draft (draft-ietf-mboned-ipv4uni-based-mcast) defining an extension to the IPv4 multicast addressing architecture
allowing for unicast-prefix-based allocation of multicast addresses so that multicast
addresses can be identified without the need for inter-domain allocation protocols. The
mechanism may have limited applicability since only two multicast addresses can be
allocated on each link and Thaler asked the meeting if there’s still any interest in this draft.
Chair (David Meyer) asked that the question be taken to the mailing list.
Pekka Savola presented a possible new BCP WG draft giving an overview of the Internet
Multicast Addressing Architecture (draft-savola-mboned-addrarch). The background for
this is the lack of updated documentation of multicast addressing. Thaler raised an
objection on the use of the word “architecture” and Pekka accepted to change the document
title. The draft was accepted as a WG work item.
Lehtonen presented a possible solution to the challenge of supporting multi-source in
source specific multicast (SSM). The personal draft (draft-lehtonen-mboned-multissm)
describes a technique combining standard SSM network functionality with end-host
supported multisource discovery using MSDP. An implementation is available. Thaler
raised objection to this technique since it is in conflict with the service model of SSM.
Perkins stated that he wasn’t sure which problem this actually solved since the end-hosts
needs to have a knowledge of the “group controllers”, i.e. that there’s a need to know actual
addressing information and not just the “channel”. Because of this, he said that the multisource problem should be solved at the application level. Stig Venaas disagreed since the
idea is to announce the group controller and not the actual SSM-address. Perkins said that
using SIP should solve this; you just have to read the 3000 pages. The Chair (David
Meyer) felt that this was an area where the WG needs input from several other WGs.
Tsunemasa Hayashi presented the draft “Accounting Issues in Well Managed IP
Multicasting Services” (draft-hayashi-maccnt). The motivation for this work is that network
operators want accounting mechanisms and there’s no accounting capabilities provided by
the current standards (based on IGMP/MLD). The proposed solution is to use IGMP and
MLD to implement the collection of accounting information in the network edges and
updating a dedicated accounting information database. A person from the audience
identified a problem since the link-provider usually is independent from the content
provider. Pekka Savola felt that there’s a need to work on the framework. Anyway, the WG
accepted this as a work item.
The last item of the agenda was the challenges and solutions to IP-multicast over MPLS.
The intention was to give an introduction to what’s going on in MPLS, present candidate
solutions for multipoint over MPLS and to discuss the possibility to create a consistent
framework. The chairs view was that people wanting to use P2MP TE tunnels to give
guarantees on IP multicast flows, should bring their requirements to the appropriate
multicast WG. He also stated that it might be possible to extend PIM-SM, PIM-SSM and/or
32 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
MBGP to support guarantees for IP multicast flows. Any further work on this requires
coordination with MPLS for coordinating multicast sessions and tunnel endpoint
identifications as well as joins and leaves.
IETF 60 (Marius Clemetsen):
See (http://www.ietf.org/proceedings/04aug/minutes/mboned.htm) for the IETF meeting
minutes.
Jerome Durand presented "Assignment of IPv6 Multicast Addresses with DHCPv6" (draftjdurand-assign-addr-ipv6-multicast-dhcpv6-00.txt). The draft proposes to use DHCPv6 for
address assignment for IPv6 multicast. He argued that some existing protocols are too
complex, are not scalable or cannot represent all types of ipv6 addresses. DHCPv6 is
widely deployed and flexible, and makes it possible to assign more than one multicast
address per host. There was some discussion whether we need this. The author argued that
we need it to obtain the address mapping to the RP. Dave Thaler stated that MADCAP
contains all elements, both for IPv4 and IPv6. It was stated that if only IPv6 is provided,
using DHCPv6 would be simpler. The discussion was "taken to the list".
Jerome Durand presented the draft " Embedded-RP and control mechanisms". There were
some discussion regarding MSDP history, and why embedded RP is needed. A problem
with embedded RP is the current lack of control of which hosts can use the RP. There is a
need to allow external users only if internal users already instantiated the session. It was
stated that group-address register filtering is not enough. ISPs also loose control of which
RP is used, and must depend on 3. party. It was stated that ISPs are willing to use 3. party
RP today. Jerome wanted to know if one should proceed with this....Chair: Take it to the
list!
There was a review and status of working group items:
•
draft-ietf-mboned-auto-multicast-02.txt
•
draft-ietf-mboned-ssm232-08.txt
•
draft-ietf-mboned-embeddedrp-06.txt
•
draft-ietf-mboned-ipv4-uni-based-mcast-01.txt
•
draft-ietf-mboned-mroutesec-02.txt
•
draft-ietf-mboned-msdp-deploy-06.txt
•
draft-ietf-mboned-rfc3171bis-02.txt
Most drafts are in final stage, and soon ready for last call.
Bill Fenner presented MSDP MIB update. Chair commented: They wanted to shut down
MSDP group, and took MSDP MIB to this group. It was renamed to draft-ietf-mbonedmsdp-mib. There had been some changes based on feedback, and some MIB
inconsistencies have been fixed. There was some concern that people may have
implemented deprecated elements. There was a proposal to check this on the mailing list. It
was stated that it should be made clear that the reason that this draft is IPv4 specific is that
MSDP is only for IPv4.
Pekka Savola presented "Multicast Deployment Issues" (draft-savola-v6ops-multicastissues-03.txt). The goal is to provide historical reference by describing issues with SSM,
why not MSDP for v6 etc. Also have a section on IGMP/MLD snooping problems. Write
Telenor R&D N 4/2005 - 33
Report from IETF meeting attendance 2004
down what has been discussed so it doesn't reappear in discussions. It was accepted as
Working Group item!
Meylor/Meyer presented an update on the IMDOC Initiative. There was a discussion
regarding the many documents describing multicast address allocation. It was suggested to
write a unifying "guidance" document.
Yiqun Cai presented MP-LSPs (Multi-Point Label Switched Paths). They try to provide a
solution for service providers to transport multicast traffic for the same customers to whom
they are providing MPLS forwarding unicast traffic. It was presented to inform on the work
done in the MPLS WG.
IETF 59 (Frode Kileng):
Greg Sheperd presented the status of SSM (“Source-Specific Protocol Independent
Multicast”) (draft-ietf-mboned-ssm232-07.txt). This is basically finished but, as several
other WG also has experienced, there’s been a problem with a normative references (MSDP
and PIM still unsolved) in draft standards to a proposed standard. SSM solves two main
problems with other proposed multicast solutions on multicast on a global scale. By
referencing the multicast source in the group address, there’s no problem locating multicast
sources between multicast domains. Inter domain protocols for maintaining distribution
trees are also not needed. SSM also solves the problem with possible multicast group
collision between logically independent multicast groups since the source address is
embedded in the group identifier. The work on SSM will go to sleep for at least 6 months
awaiting the progress of MSDP and PIM.
The draft-ietf-mboned-msdp-deploy-05.txt draft describes BCP (Best Current Practice) of
the deployment of MSDP (Multicast Source Discovery Protocol). Since MSDP is still an
experimental protocol, there’s also a ”referencing-problem” in this document. MSDP is a
”peering-protocol” solving the inter-domain challenge of multicast between separate PIMdomains.
Pekka Savola presented a threat analysis (draft-savola-mboned-mroutesec-00.txt) on
possible security problems with PIM-SM, MSDP and Embedded RP. Embedded RP is a
technique where the address of the RP (Rendezvous Point) is embedded in the multicast
group address, i.e. a solution to interdomain multicast. This work was initiated after the
discussion of possible security problems with Embedded-RP. Three PIM-SM threats are
identified: Receiver-based (”false” joins to different groups), source based (sending
multicast to empty groups or disturbing existing group by ”illegal” traffic) and threats
related to aggregating factors (distant RP/source problem using invalid PIM message
addresses). The draft suggest several solutions to the problems, many which are rather
controversial: Drop the use of MSDP for inter-domain multicast, implement PIM ratelimiting mechanisms in multicast routers, support ”return routability” checks (before
creating state in routers) and to change the PIM-SM specification to test for valid neighbors
instead of just checking for the ”correct interface” in the reverse path verification. The
meeting decided to accept the personal draft as a WG item.
Status of the Embedded-RP draft (draft-ietf-mboned-embeddedrp-01) was presented by
Pekka Savola. There have been a few changes since version 00. The draft will be sent to the
mailing list for WG last call.
Dave Thaler presented the draft ” IPv4 Automatic Multicast Without Explicit Tunnels
(AMT)” (draft-ietf-mboned-ipv4-uni-based-mcast-01.txt) that proposes a solution to the
problem of sending and receiving multicast traffic when located behind a NAT. The
technique has some similarities with Teredo and support automatic tunneling of multicast
traffic over NAT using IP in UDP encapsulation. It makes it possible for a node behind a
34 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
NAT to receive SSM and ASM specific multicast traffic and to send SSM traffic from a
public IPv4 address. As with Teredo, AMT uses relays as tunneling endpoints, relays that
may be public and out of local administrative control. There was a lot of discussion
regarding the draft in the meeting to clarify security issues relating to the suggested 3-way
handshake before enabling state in the public relays. There where also someone questioning
the need for yet another tunneling protocol instead of utilizing existing protocols.
John Meylor presented the current status of the IMDOC (Internet Multicast Documentation,
Oversight, and Coordination) initiative. IMDOC is intended to serve as a locus
documentation, cross-coordination, and oversight function for the multicast activity in the
IETF at large. It will create two crucial missing components in the deployment of mbone in
the current Internet: a) A comprehensive IETF multicast framework document and b) the
Internet Multicast Reference Architecture (IMRA). The first step in IMDOC is an analysis
and clarification of the problem space (The “multicast address allocation issues” draft (see
next paragraph) is part of this). Meylor asked for volunteers to participate in the IMDOC
work.
Dave Mayer presented the draft ”Multicast Address Allocation Issues” (draft-ietf-mbonedrfc3171bis-01.txt), an update on the IANA guidelines for allocation of IPv4 multicast
addresses. There’s an immediate and fundamental problem today when IANA gets
requested for the allocation of global multicast address space. All of the dynamic multicast
address allocation techniques like SDR or MALLOC is said to have failed in practice so
static allocations is currently the only solution. In the discussion there were many attendees
that pointed out that applications utilizing multicast often do that due to the need to locate
services and resources. And this is because resource and service location mechanisms like
SLP have failed, probably due to their heavy weight.
3.4.3 PIM (Protocol Independent Multicast)
IETF 61 (Frode Kileng):
Stig Venaas gave a presentation of the current “Bootstrap Router (BSR) Mechanism for
PIM” (draft-ietf-pim-sm-bsr). The responsibility of this draft was given over to a new group
of people since the original authors didn’t want to finish the work. There are several issues
with the current draft that needs to be solved. His presentation mostly related to the
problem of maintaining the group-to-RP mappings (strategy for withdrawal of an RP from a
group range) and to the IPv6 multicast Scope mapping to BSR (separate BSR election for
each range?).
Boers Arjen gave a presentation of the status of “The Proxy Field in PIM Join Messages”
(draft-wijnands-pim-proxy). This was introduced at IETF60 but failed to reach rough
consensus and this was a version trying into account many of the objections. The draft
defines an extension enabling PIM to build multicast trees through an MPLS-enabled
network, even if that networks IGP does not have a route to the source of the tree. Three
proxy-types are described: vector proxy, MDT-SAFI Proxy and a Vector Stack Proxy.
After an objection from an audience, the presenter agreed that the word “proxy” should not
be used.
An accounting supporting mechanism for PIM was presented in the draft “Population
Count Extensions to PIM “ (draft-farinacci-pim-pop-count). The chair asked if
“accounting” should rather be solved at a generic level, for example in the magma WG, to
avoid making PIM more complicated than it already is.
Telenor R&D N 4/2005 - 35
Report from IETF meeting attendance 2004
Chair informed that the chairs of all multicast related WG intended to meet during IETF61
to discuss where and how to solve the issues related to the proxy (draft-wijnands-pimproxy) and accounting (draft-farinacci-pim-pop-count).
3.4.4 RMT (Reliable Multicast Transport)
IETF 61 (Frode Kileng):
Short status of current drafts: “FLUTE - File Delivery over Unidirectional Transport” is
finished and published as an experimental RFC3926. The draft “NACK-Oriented Reliable
Multicast (NORM) Building Blocks” (ietf-draft-rmt-bb-norm) and “NACK-Oriented
Reliable Multicast Protocol (NORM)” (draft-ietf-rmt-pi-norm) is approved by IESG and
will be released soon.
Mike Luby presented “The Raptor Forward Error Correction Code (FEC)” ID) describing
how to use Forward Error Correction (FEC) codes for reliability of data transport.
Lorenzo Vicisano gave an introduction to a possible evolution of FEC BB (Forward Error
Correction Building Blocks). The FEC BB draft (draft-ietf-rmt-bb-fec) will be resubmitted
as draft intended for standard track. The goal is to update FEC-BB in a backwardcompatible way. The enhancement will support streaming by explicitly allowing the use of
certain FEC encoding IDs for streaming and also working out a strategy for defining
streaming profiles for FEC encoding ID's.
Mike Luby then went further into FEC BB applied for streaming and raised the question
“Should FEC BB be extended to support streaming?” He felt that the results from
experiments with FLUTE shows that it’s now time to work out solutions for reliable
multicast. Also the 3GPP SA4 MBMS service has adopted a FEC protection architecture
for RTP streaming data that fits in the FEC BB. There was a discussion about the use of
“Reliable” since these mechanisms increases the reliability, not making it completely
reliable. It was also a concern with applying this streaming since there’s a very large
overhead when used on small packets since the “repair packet” has to be large enough to
correct the source packet.
36 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
4 Reports from BoF sessions
4.1.1 PERM (Protected Entertainment Rights Management) BoF
IETF 60 (Marius Clemetsen):
Systems for controlling access to multimedia content like TV, music and Video on Demand
can be roughly divided in two categories: DRM (Digital Rights Management) and CAS
(Conditional Access Systems). DRM systems implement protection for digital content that
is distributed on the Internet, and they also provide methods for preventing illegal use (like
copying content and re-distributing it after download). CAS systems has traditionally been
used for protecting pay-TV, and do not implement copy-protection mechanisms as the
content has been provided to the user as an analog signal out of the set-top box (which
cannot be copied without degradation).
The DRM and CAS systems of today are proprietary, and typically implement methods for
key distribution, AAA (authentication, authorization and Accounting) and encryption.
PERM is an initiative from several vendors (Cisco, Pioneer, Verisign, ..) for standardizing
the PERM (Protected Entertainment Rights Management) protocol. It has benne worked
upon for 3 years in the DENi consortium. PERM is supposed to provide secure usage rights
management by defining functions for transporting credentials for AAA, establishing keys
for content encryption/authentication and providing a rights management payload for
specifying how the content can be used. The idea is to identify and standardize the nonproprietary pieces of the DRM/CAS solutions. The authors argued that today we have
standards for key exchange, but not for the combination of key exchange and protection of
rights management information.
There were approximately 70 people at the meeting. The meeting started with presentations
of PERM. After that there was a discussion. The authors stated that they have already made
a complete protocol specification that they want reviewed in the IETF, and not just post it
as informational. They are open for discussion of the PERM protocol, and may trade
elements of PERM for IETF standards where appropriate. Want to make PERM fit well
with the IETF protocol suite/architecture. The opponents argued that we already have
standards for key exchange, and that the protocol doesn't address important parts, like how
to protect the content on the box (the authors says this is out of scope). One person said that
by standardizing this protocol we would only add another member to the zoo. See minutes
(http://www.ietf.org/proceedings/04aug/minutes/perm.htm) for more details of the
discussion).
Vote: approximately 20% for, 30% against, 50% undecided.
4.1.2 IPv6 over IEEE 802.15.4 BoF
IETF 61 (Frode Kileng):
The BOF started with an introduction and presentation of the problem area. Geoff Mulian
from Invensys said that ZigBee is not an alternative to 6lowpan since ZigBee's stack is so
big (64k), complex, expensive, untested and lacks IP compatibility.
Telenor R&D N 4/2005 - 37
Report from IETF meeting attendance 2004
Jose Gutierrez, program manager for the ZigBee specification, gave an overview of IEEE
802.15.4. The IEEE has two task groups working on improving 802.15.4 named 802.15.4a
and 802.15.4b. The 802.15.4.a is extending the standard, for example with support for
location information. The WG expects to finish its work in November 2004. Jose stated that
he doesn’t like this WG since it breaks the “low cost”, and the work belongs to 802.15.3.
802.15.4b WG tries to resolve some ambiguities. The WG may be open for input on
\possible requirements for supporting IPv6. The 4b WG is planned to complete its draft
January 2006.
Nandakishore Kushalnagar (from Intel) presented ideas for a 6lowpan problem statement
(draft-6lowpan-goals-assumptions.txt). He told that Intel initially joined ZigBee but backed
out due to legal issues. Nandakishore defined Lowpan with the keywords: low cost (<$10),
low power (small batteries, months/years runtime), low bandwidth, high density (#
devices), star & mesh topology, IP network interaction, and physical MAC-layer mapping
over 802.15.4 and possible 802.15.3! Challenges for 6lowpan are the low power
consumption, cost and bandwidth. Issues related to routing include periodic sleep aware
routing, low overhead, small or no routing tables, low routing overhead, scalable,
routability to "any node", and seamless IP routing. Addressing issues to regard is storage
limitations (low overhead), stateless address generation, compressed addresses and large
address space (ipv6). An important issue relates to the overhead of mapping IPv6 over
802.15.4. The max MAC frame size of 15.4 packet is 127 bytes with a maximum payload
of 102 bytes. With security, the payload is down to 81 bytes in the worst case!
Nandakishore further defined some goals for 6lowpan: If possible reuse existing protocols ,
solve the mismatch between 802.15.4 MTU size (102-81 bytes) and IPv6 requirements
(1280 bytes), stateless auto configuration support, header compression, security
model/mechanisms/configuration/bootstrapping and network management, suitable routing
(manet? topology aware? below L3 and/or above L3?). A lightweight discovery mechanism
may also be required. Another problem with v6 over 15.4 mapping is that v6 mandates
security. A person from the audience proposed to remove the 802.15.3 as a mapping target.
Another warned that stateless security is extremely expensive.
Gabriel Montenegro from SUN outlined the MAC layer mapping, i.e. “Transmission of
IPv6 packets over IEEE 802.15.4”. He identified the need for a shim-layer (adaption layer)
due to the mismatch between v6 MTU requirement and max 802.15.4 max payload. This
shim-layer may also include other functions as header compression and meshing solutions,
either layer 2 mesh (AODV lite?) or layer 3 mesh (inter PAN). The MTU size problem was
discussed further in the meeting and Brijesh said the 15.3 spec was done and the shim-layer
could not be included there. The goal to finish the v6 over 15.4 draft in March 2005 was
also said to be too ambitious.
Geoff Mulligan initiated a discussion of an IPv6 profile for IEEE 802.15.4. It's uncertain
what such a profile should include and if similar profiles exist for other MAC layer
mappings. The profile could include: 15.4 MAC Lite (“minimac” suggested!), AODV Tiny
(NOT on top of IP), IPv6 (stateless header compression), UDP (reliable UDP?), SNMP-Lite
and APIs (socket/ioctl/serial). To support reliable data transfer, input from a WG
participant suggested sticking with TCP. Another participant said that the network might
not be uniform since some devices may have more resources. Geoff told they had running
code! An experimental implementation of this shows that MAC+AODV=8K,
IPv6/UDP/Serial=12K not-optimized and a where a complete stack should be < 20K.
The next item on the agenda was a possible draft of a WG charter. Deliverables on the draft
was rather ambitious. The problem statement, to be sent to IESG as informational, should
be finished by January 2005. March 2005 is the delivery date of the “v6 over 802.15.4”
draft, intended as a PS. The lowpan profile draft (IPv6 profile for IEEE 802.15.4), intended
as a BCP or Informational, should be done before June 2005. Other candidates for WG
38 - Telenor R&D N 4/2005
Report from IETF meeting attendance 2004
work items, eventually to be added after a WG re-chartering, includes ultra-wide band,
lightweight discovery and secure bootstrapping.
In the open discussion part of the agenda, participants raised concerns about the “crippled”
versions of other standards (AODV, SNMP, etc). The “protocol-owner-guys” may claim
that this is not the actual standard but something else. IPv4 support was another topic raised
in the discussion. But there seemed to be a common understanding that IPv6 is the only
choice.
The meeting voted unanimously to create a 6lowpan WG in IETF to address this problem
area.
Telenor R&D N 4/2005 - 39
Report from IETF meeting attendance 2004
Significance for Telenor
IP-technology is strategically important for Telenor's Business, and will continue to be so in
the future. The work undertaken in the IETF represents the state-of-the-art of IP
technology, and the IETF include technical scientists and developers that are in world-class
in terms of competence within their fields. It is important for Telenor to do technology
surveillance in a forum that is in the forefront of the development.
40 - Telenor R&D N 4/2005