Participant’s Report on IETF-77 at Anaheim
Report from Palanivelan, Cisco
I was one of the ISOC fellows that attended IETF77 at Anehaeim,ca. This was my first IETF meeting and the experience was a wonderful and very useful one. This is where we get to discuss the higher priority issues on internet technologies and discuss possible solutions for them. The opportunity to participate and make your views heard at the biggest stage is wonderful and a good learning at that.
The Internet Technical Community members who are IETF regulars found that I am from INDIA wondered why there was a less representation from my country and the only reason I could say is lack of Knowledge about these Meetings and IETF as such. People are expecting a bigger participation from INDIA and when the message is spread, I am sure there will be more from this country that would actively engage in working for a bigger output.
I personally was looking at understanding and pushing my drafts up to RFC and attending this meeting made me well equipped in moving with the process and achieving it. I like to share some of the useful presentations and discussions from this meeting.
Let me start with the general (non-working group) presentations and discussions that occurred during IETF-77.
New comer’s training:
Very useful for the first–timers and had quite a lot of useful information.
This presentation gave an overview of the IETF organization (Internet Society, IAD, IANA, IAB, IESG), the details on IETF efforts, Breakup of activities on areas at present ( Applications – 15 WGs , Internet – 28 WGs , Operations & Management – 15 WGs, Real-time Applications and Infrastructure – 19 WGs, Routing – 16 WGs , Security – 17 WGs Transport Services – 14 WGs) and about the RFCs (Standards, Best current practice, Informational, Experimental and of course the april1-RFCs).
NAT Tutorial by Dan Wing:
This presenter was a co-chair for behave-wg and the presentation was very informational and a very useful one for those interested in NAT/Security area. The first part of the tutorial covered the history and the basics of NAT. It then focused on the design and implementation scenarios and continued to discuss on the latest work on NAT (like Nat64, Nat444, Nat66 and ALGs).There were extended discussion on the NAT translation issues and also on the challenges for NAT with respect to migration to IPv6.
ISOC Panel discussion: IPV6 are we there yet ?
Most of the discussions in the v6ops working group had questions asked, on why there is a need for work on any v6 migrations at this point of time and no one had answers to when the inevitable (V6 migration) is to happen. This panel discussion threw light in clearing the doubts and questions on this and pretty much had facts put forward and made a reasonable and acceptable points on why we should focus on the migration.
http://www.isoc.org/isoc/conferences/ipv6momentum/
Let me quickly summarize the take aways from the working group discussions that I attended.
v6ops: IPv6 Operations
There was lot of interest on this working group and I would say was the hottest working-group this meeting. Whenever a draft came up for discussions, a good number of people had apprehensions on moving to IPv6 itself and this was the case with most of the meetings.
Some of the interesting documents that were discussed include..
- RFC 5006, “IPv6 Router Advertisement Option for DNS Configuration” (This RFC specifies mechanism for host to get DNS server information from RA (SLAAC) without the use of stateless DHCP server)
- “Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service” (This draft defines filtering mechanism for common protocols like TCP, UDP, ICMP to provide similar security as NAT in IPv4. However, it has grown bigger over time and include advanced protocols like DCCP, SCTP, & SHIM6)
- “Advanced Security for IPv6 CPE”( IPS subscription based technology since security policy would require constant update and Cisco set out to implement this draft)
- “Stateless IPv6 Prefix Delegation for IPv6 enabled networks” (This draft got its idea from 6to4 and 6rd… Instead of using IPv4 address to create the prefix, we can use unique key in the network (e.g. 3GPP, GRE key, …) to form IPv6 prefix)
- “Unicast Transmission of IPv6 Multicast Messages on Link-layer” (Some IPv6 multicast packet should be able to send unicast on L2 to save network bandwidth or for security reason. For example, the RA message can send to specific host in a WiFi network belonging to this prefix)
- “Advanced Requirements for IPv6 Customer Edge Routers” (It defines advanced IPv6 features for CPE devices like QoS , Service Discovery, DNS, Multicast,Multi-homing).
There was also discussion on “Emerging Service Provider Scenarios for IPv6 Deployment”. This had results of the survey responded by 30 ISPs on IPv6 deployment. The forum was not completely in agreement with the points and the numbers discussed and felt that the results may not reflect the actual scenario in full.
6lowpan: IPv6 over Low power WPAN
This WG is not to our immediate interests but might be in the future for home monitoring solutions. For the starters, 6LoWPAN is an adaption layer for IPv6 over IEEE 802.15.4 links. This is not a protocol stack and will provide a full solution for smart objects networks.This shall performthree functions namely packet fragmentation and re-assembly, Header compression andNeighbor Discovery.
The interesting drafts under this working group includes, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks”, ( low power devices using 802.15.4 (PAN) to support IPv6, issues with fragmentation and header compression for small size packets), “Simple Neighbor Discovery”, simple-00.txt> (propose simplified ND to resolve performance and complexity issues in mesh network) and “Simple DHCPv6 for 6LoWPANs”, txt> (simplifying DHCP to be worked in mesh network).
IETF 6lowpan references to 802.15.4 standard (802.15.4-2006: draft-ietf-6lowpan-hc-06.txt ) andmoving 802.15.4 to newer version was considered.
behave-wg: Behavior Engineering for Hindrance Avoidance
This working group is mostly concerned with IPv4 and IPv6 interworking solutions. The main purpose for this meeting is to define new charters and milestones.
There are quite a number of documents int the IESG review stage and are expected to become RFCs pretty soon. There were quite a few scenarios considered and discussed in behave that includes ipv6 network to IPv4 Internet , v6v4-xlate, dns64, v6v4-xlate-stateful, IPv6 Internet to an IPv4 network, xlate-v6v4-stateful, dns64, An IPv4 network to IPv6 Internet, IPv4 Internet to an IPv6 network, etc..
The IETF-3GPP workshop on IPv6 migration had the above scenarios (for IPv6 migration) discussed and validated. It was recognized that necessary support in the network and devices is already available to “switch on” IPv6 in 3GPP networks. Solutions enhancing existing mechanisms for dual stack deployments and new solutions for IPv6-only deployments drew wide support.
As part of “IETF77 NAT64 Experiment”, Trial of open source nat64, dns64 implementation during IETF sessions were performed and the problems and statistics were summarized.
– Palanivelan, Cisco, Participant
..