Tomohiro Fujisaki / Arifumi Matsumoto
NTT Information Sharing Platform Laboratories
1. Overview of IETF 69 Meeting
IFTF 69 Meeting was held in Chicago, USA, from July 22 through 27, 2007. The meeting gathered 1,146 people from 40 countries around the world this time, as reported at the plenary session (a general meeting held in Wednesday evening everytime). The IETF 68 Meeting held in Prague, Czech Republic got 1,129 people from 45 countries participated. The last several IETF meetings saw around 1,100 attendees. Figure 1 shows the historical trend of the number of attendees. As shown in Figure 2, the United States and Japan are dominant in terms of the nationality of attendees, much like the last meeting.
2. IEPG (Internet Engineering and Planning Group) Meeting
IETF Meeting usually starts in the afternoon of Sunday of the conference period. Prior to that, IEPG meeting is held on Sunday morning. IEPG meeting often discusses topics on internet operation and address management. This time, there were several IPv6-related presentations. Of particular interest was a presentation on IPv6 transition by Mr. Randy Bush, titled "IPv6 Transition & Operational Reality". He cited various myths including: "IPv4 is running out", "IPv6 transition is easy","IPv6 eliminates NAT", and "IPv6 reduces routing load". He pointed out various "must-do"s for each area of concern (servers, corporate, applications, etc.) for future deployment of IPv6. Too bad that we had little time left for discussions. Other presentations included IPv6 deployment case study and IPv4 address depletion. Presentation materials are available on IEPG Web.
IEPG web
http://www.iepg.org
3. dhc WG (Dynamic Host Configuration WG) Activities
dhc WG discusses on DHCP(v4) and DHCPv6 mechanisms and define new options. IPv6-related topic this time includes introduction of DHCP test tools and distribution of IPv6 default router information through DHCPv6.
DHCPv6 test tool overview was given by TAHI Project, which conducts IPv6 spec conformance testing. The tool can test if implementations of DHCPv6 servers, relay agents, and clients conform to DHCPv6 basic spec. The project also reported that IPv6 Ready Logo certification began on DHCPv6. They also talked about implementation testing results. They don't see many client implementations yet, they said.
The hottest debate this time was on DHCPv6 extension, presented with the title: Extensions to DHCPv6 for prefix and default router information. With IPv6, Router Advertisement (RA) messages are used to notify IPv6 addresses of routers on the network. It is possible that IPv6 communication is hindered by a node on the same segment transmitting this message inappropriately due to configuration error and other reasons. In fact, this problem is commonly observed at IETF and other various event networks. This issue also allows malicious attempt to transmit RA intentionally to redirect other people's packets.
One proposal on this issue presented at the meeting was transmitting default router information through DHCPv6, much like IPv4. But the proposal was countered by opinions such as that it affects IPv6 basic specification, that it won't offer fundamental solution (authentication by DHCP server is required), and that there are other measures to take (such as the use of protocols to secure RAs). The proposal of extension to distribute router information was not agreed upon.
The same issue is also discussed in v6ops wg.
IETF 69 dhc WG meeting agenda
http://www3.ietf.org/proceedings/07jul/agenda/dhc.html
4. v6ops WG (IPv6 Operations WG) activities
v6ops WG, a working group that discusses IPv6 deployment issues and IPv6/IPv4 coexistence technology, had a meeting in the first session slot on the first day. Mr. Fred Baker, the WG chair, first explained status of WG documents, whether each one of them was submitted to RFC editors, being worked on by AD, or working group last call (WGLC) done. Then, the WG mainly discussed on the following topics:
- source address selection
- CPE security topics
- Teredo topics
- DHCP topics
The first item, discussion on source address selection is about the method of selecting source address to use by a host with multiple addresses. At the last meeting, originally proposed draft (draft-ietf-v6ops-addr-select-ps) and solution requirement draft (draft-ietf-v6ops-addr-select-req) reached WGLC status. The author of this article explained responses to the comments on the mailing list and proposed additional draft revisions. At this meeting, there were no major additional comments on the two drafts, and these drafts moved to the next stage. Then, draft-arifumi-v6ops-addr-select-sol draft was explained by the author of this article as a solution to source address selection problem, followed by discussion. Opinions expressed on solutions, for example, were that none of the solutions proposed by the drafts were realistic in terms of deployment, that multiplex was unnecessary in IPv6 networking, and that solutions need to be selected case by case, as no one solution can cover all cases. After the discussion, WG chair asked for a vote whether this solution draft should be treated as a WG item. More people voted for the draft than opposed it, but it was judged that it had not garnered consensus to become a WG item. The draft was put to further discussion.
The second item, CPE security issue, was about CPE (Customer Premises Equipment) devices on small office and home networks. There is a draft called draft-ietf-v6ops-cpe-simple-security on this issue. The discussion centered on how IPv4 security with NAT and CPE security automation protocol (such as UPnP) should be treated with in IPv6. There were especially many opinions voiced about firewalls in IPv6. One said firewall is unnecessary in IPv6, as firewall would mean introducing NAT to IPv6, but hosts should guard themselves, and no problem is encountered although one lives daily in such environment. No conclusion was reached on this discussion, and left for further discussion on ML.
The third item, issue on Teredo was a call to attention on Teredo security, as detailed in draft-hoagland-v6ops-teredosecconcerns. Teredo is a protocol to create IPv6 over IPv4 tunnels over NATs, and is equipped with Windows Vista and others by default. It is a convenient way to enable IPv6 communications using IPv4 network environment. But it is pointed out to pose a security risk of inadvertently bypassing firewalls/NATs. Administrators are currently recommended to prohibit the use of Teredo or filter Teredo (UDP) packets. This draft was adopted as a WG item for further discussion.
The fourth item, issue on DHCP, was identical to the issue discussed at dhc WG meeting in the morning of the same day. The same speaker made the same presentation. Mainstream opinion in v6ops WG was that DHCPv6 server authentication and SEND (protocol to secure RAs) should be used as solutions to this issue, and that distributing router information through DHCPv6 would only make problem worse.
IETF 68 v6ops WG agenda
http://www3.ietf.org/proceedings/07mar/agenda/v6ops.txt
5. shim6 (Site Multihoming by IPv6 Intermediation) WG activities
No shim6 WG on-site meeting was held this time (at the IETF meeting before last, it was decided that specific discussion should be conduced at this meeting, based on shim6 implementation which should have been available by now). After the meeting, WG chair reported that they were working on 3 drafts on basic shim6 protocols to make them RFCs.
6．Other IPv6-related activities
IPv6 WG was supposed to conduct no more on-site meetings, only proceeding with existing IPv6 spec standardization. But some issues arose which require activities as IPv6 WG. It was decided that a new IPv6 WG meeting will be conducted during the next Vancouver IETF Meeting. The current IPv6 WG will be closed, and a new WG will be created only for IPv6 maintenance purpose. The name of the new WG is IPv6 Maintenance Working Group. It will focus on the following activities:
-RA flag option
-Type 0 routing header disabling
-PPPv6 header compression
-Discussion on ULA Central
7. ram (rrg)-related activities
The last IETF 68 Meeting had ID/Loc Separation BoF in Internet area (intarea) sessions. The BoF discussed routing scalability issue in default free zone (DFZ)(http://www.ipv6style.jp/jp/20070331/ietf2.html). Discussions continued on various proposals based on the idea of ID/Loc separation on mailing lists such as ram(Routing and Addressing) and rrg(Routing Research Group). In this IETF Meeting, a whole day was spent for rrg sessions on Friday, the last day, and presentations and discussions were conducted mainly on proposals made on ram mailing list (this is rare because IETF Meeting usually ends on Friday morning).
This routing scalability issue is not only related to IPv6, but it already is evident in IPv4 as routing table explosion problem. The problem is forecasted to become even worse in IPv6, because of larger address space and longer prefix length. This is an important topic in supporting present and future Internet.
At the meeting, rrg chair Mr. Tony Li presented update status on the draft on the next generation routing architecture design goal. After that, Ms. Lixia Zhang presented on solution approach classification, offering her analysis on various methods of ID and Locator mapping management as well as communication failure detection and usage.
As the Routing Research Group, the meeting included 2 research presentations. One was from the University of Kentucky, explaining the research to improve scalability by hierarchical routing and forwarding. The other was from Universit? Catholique de Louvain, explaining the research on the cost of ID/Location mapping cache size, mapping resolution traffic, etc. The research used ID/Loc separation protocol called LISP for cost estimate. It applied the user traffic observed on the university network and BPG table. The presentation showed that it depends on cache timeout setting, but mapping system can be realized with a framework like existing DNS.
As for the main topic, the discussion on ID/Loc separation, two major methods, LISP and SIX/One, and their variations were presented. LISP is the abbreviation for Locator Identifier Separation Protocol. The protocol enables multihoming with no change to the hosts, by packet capsuling and de-capsuling between tunnel routers at the sites communicating hosts reside in. In-site address is used as Identifier, and addresses given to tunnel routers for use for packet capsuling as Locator.
SIX/One method is based on shim6 protocol, a host-based multihoming method having been discussed in IETF shim6 working group. It allows change of packet address field at intermediate routers. This enables multihoming to reflect the policy of site administrator at ISP and others. But as with shim6, it requires change in host protocol stack, posing a possible problem in deployment.
There were other presentations on LISP adaptation/extension methods, APT, LISP-CONS and LISP-NERD, followed by active discussions. In particular, LISP method is attracting the most attention on ram mailing list, while implementation has already started. It appears that IETF is moving on an exceptionally rapid pace to put this to practical use. It seems that the success will depend on how effective and practical standalized method will be, through reflecting inputs from operator communities and others.
IETF 69 rrg agenda
http://www3.ietf.org/proceedings/07jul/agenda/RRG.html
IETF 69 rrg materials
https://datatracker.ietf.org/meeting/69/materials.html
The following URL offers links to various IETF 69 Meeting sessions:
-Overall program, WG agenda, materials
https://datatracker.ietf.org/meeting/69/materials.html
-Recording
http://videolab.uoregon.edu/events/ietf/
