IETF 6MAN Working Group Meeting Tuesday, March 24, 2009 San Francisco Hilton, Continental 6, 1710-1810 Co-Chairs: Bob Hinden and Brian Haberman The meeting was called to order by 6MAN co-chairs Brian Haberman and Bob Hinden. The minutes were taken by Karen O'Donoghue. The Jabber Scribe was Margaret Wasserman. The blue sheets were distributed, and the agenda was presented with no additions. Brian Haberman reviewed the current working group document status. In particular, the overlapping fragments document had only one comment received. Suresh addressed the comment and updated the draft. However, the draft received no comments supporting advancement. Working group members need to post endorsements on the mailing list. (agenda and document status slides: 6man-2.pdf) IANA Routing Header Registry, Jari Arkko ===================================================================== Draft: draft-arkko-ipv6-iana-routing-header-00 No slides This draft proposed IANA guidelines for requests for any new routing header types. This guideline states that all requests must come through the IETF process. Jari is not aware that this is stated in any existing RFC. Suresh indicated that he does not know of any RFC that defines this and thinks this one is fine. WG members are asked to read the document and post any comments to the mailing list. Address Selection Design Team Update, Tim Chown ===================================================================== Draft: draft-chown-addr-select-considerations-02 Slides: 6man-3.pdf Tim Chown provided an update on the address selection design team which has been tasked to look at revising RFC 3484 to address policy update requirements. The current scenario is focused on the enterprise or site network where the administrator wants to convey policy to hosts. Changes from the -01 draft include discussion of nomadic hosts, the multiple interface issue, policy conflicts, push versus pull solutions, and a default policy indicator. The design team raised a number of topics for discussion by the working group including the frequency of updates, the issue of IPv4 NAT/IPv6 transition, the relationship between this effort and the MIF BOF, multiple administrative domains, policy conflicts, default policies, and the use of routing information to assist in the address selection decisions. Several comments and questions were raised. Thomas Narten pointed out that we have tended to assume a simple host with one interface when the reality is that hosts have multiple interfaces. The design team began to address this in multiple admin domains. A question on the relationship with the emerging MIF work was discussed. It was pointed out that MIF is currently a BOF, and 6MAN is a working group. We shouldn't worry about conflicts with MIF at this time. Dave Thaler pointed out that RFC 3484 does two basic things, destination address selection and source address selection per destination address. Dave felt it would be useful to clarify that the node-wide problem is destination address selection. Suresh indicated he felt that the bigger problem is multiple DNS servers. Dave Thaler stated that the issue of multiple DNS servers was out of scope on the draft. Thomas Narten felt that if we accept multiple admin zones, we have to address this problem. Thomas Narten pointed out that there are two kinds of changes to 3484: 1) changes that utilize existing update infrastructure but change info, and 2) changes to the update infrastructure. It would be useful to talk about what is required and what would be useful in this context. The chairs closed the discussion by stating that we will move forward with making this a working group document. Please read and comment on the draft on the WG mailing list. Proxy Mobile IPv6 Indication and Discovery, Basavaraj Patil ===================================================================== Draft: draft-damic-6man-pmip6-ind-00 Slides: 6man-1.pdf This draft deals with the situation in Proxy Mobile IPv6 created by the advertisement of a prefix or prefixes by an Access Router which is topologically anchored elsewhere. A host receiving this RA has no awareness of the prefix characteristics. This draft proposes to qualify the prefix type in the RA. Dave Thaler indicated that we still need clarification on the problem. The problem statement is an observation and there is not consensus on whether the observation is a problem or a feature. Brian Haberman directed that if the problem statement isn't clear we should spend the rest of the time on clarifying the problem and skip the solution for now. Suresh stated that the problem is indicating the quality of the prefix using the RA. Ralph Droms asked how one would use the quality of the multiple prefixes on the link. What is the host going to do with that information? What decisions are made? Dave Thaler asked what properties are meaningful to the host? Bob Hinden concluded that there was no consensus to do this work now. Further discussion clarifying the nature of the problem is directed to the mailing list. UDP Checksum for Tunneled Packets, Marshall Eubanks ===================================================================== Draft: draft-eubanks-chimento-6man-00 Slides: 6man-4.pdf Marshall Eubanks presented a document that relaxes the requirement for calculating the UDP checksum on tunneled IPv6 packets when using lightweight tunneling protocols. The rationale for allowing this is that the inner data is already protected by a checksum. IPv4 allows this, but RFC 2460 explicitly forbids it on IPv6 networks. The authors tried to identify an attack vector to quantify risk without success. Suresh indicated that he had sent a failure scenario to the list that needs to be added to the draft. Another question was is it possible to distinguish hosts from routers. This may represent another fault scenario. Further input was solicited from the WG in the area of failure scenarios. Another question was why wouldn't you use UDP-lite instead which was designed for this purpose. The problem is that UDP-lite doesn't pass through NATs or other stateful packet inspection tools. Remi asked if an incremental checksum update would work. Brian Haberman mentioned that he had received comments from the AMT authors that they don't want any checksums. There are IPv6 firewalls in development, and some folks would be surprised if they aren't doing UDP checksums for IPv6. Dave Thaler thinks this is the right way to go forward. If I did it in IPv4, I should be able to do it in IPv6. Brian Haberman asked Marshall to send a pointer to the document to the 6man mailing list with a copy to the AMT list. Please review and comment. Common Architecture Label IPv6 Security Option, Ran Atkinson ===================================================================== Document: draft-stjohns-sipso-11 Slides: None Ran Atkinson began by pointing out that his speaking for this draft in no way implied a commitment on the part of Extreme Networks. This draft supports adding sensitivity labels to IPv6 packets to indicate the sensitivity level associated with the information in the packet. It enables specialized security devices to make access control decisions. It is used where trusted operating systems are being utilized in multilevel security environments including in many countries beyond the US, e.g. the NATO countries, Singapore, and Japan. It has been deployed in a geographically diverse manner and is not for use in the public Internet. Companies that build multilevel security operating systems including Sun, HP, and IBM, have reviewed the document and found it acceptable. For IPv4, there were three different options that do essentially the same thing (RFC 1038, RFC 1108, and FIPS 188). This document provides parity between IPv4 and IPv6 and not having this or something similar is an impediment to deployment. Brian Carpenter indicated that he doesn't see a reason why we would object. Sam Hartman (via jabber) recommended that members read the document to ensure they understood the implications of its use. Erik Nordmark indicated that it is not much different than a vlan tag. Bob Hinden stated that we will confirm on the mailing list that the room is not objecting to the document. Bob Hinden wrapped up the meeting by suggesting perhaps the 6man wg should request a longer timeslot for the next meeting. The meeting was adjourned.