Tuesday, November 10, 2009, 0900-1130
Chairs: Brian Haberman, Bob Hinden
Jabber Room: 6man@jabber.ietf.org
Meeting Room: Orchid West

1. Introduction, Administrivia, and Agenda Bashing, Chairs, 5 min.
   • Potentially additional presentation from Broadband Forum
2. Document Status, Chairs, 5 min.
   • Node requirements - no update yet, discussion on list
3. A Recommendation for IPv6 Address Text Representation,
   • Document : draft-ietf-6man-text-addr-representation-01.txt
   • Presenter : Seiichi Kawamura
   • Many implementations with different preferences can cause problems; canonical representation recommended in this draft
   • Updated since IETF75, editorial, x.509 example
   • IPv4 embedded - mixed notation recommended, but sometimes can be in full test
   • [address]:port RFC 3986 remains recommended but other forms still ok
   • WG item at IETF75, WGLC ended Nov 5
   • One new outstanding comment e-mail (Jinmei)
   • Ready to advance if no other issues - take to list
   • Tatuya Jinmei - I have some comments to be addressed, not critical, may require a revision before advancing; editorial for the most part
   • Bob Hinden - clear consensus to move forward as Proposed Standard, with editorial fixes
4. 6LoWPAN Neighbor Discovery,
   • Document : draft-ietf-6lowpan-nd-07.txt
   • Presenter : Carsten Bormann
   • Right now the rest of the authors are at the ROLL WG simultaneously; may not be able to answer all questions
   • Very simple limited function nodes, very low power (2AA for two years = 200uW)
   • Not always listening (sleep mode)
   • Constrained networks - IEEE 802.15.4 and similar wireless low-power shared media, small packet size
   • Not necessarily transitive links, no multicast in general, link-local within radio range
   • Don't count on typical IP functionality
   • Therefore, need a special approach to neighbor discovery optimized for NBMA network
   • RFC 4861 not designed for this
   • Objectives for 6loWPAN ND
     • focused on host-router, no host-host
     • all ND functions, DAD, AR and NUD but not in the same way; Node Registration function
     • distributing context that all nodes need
     • both Mesh Under (MU) and Route Over (RO)
   • Link model based on 15.4; link-local scope is one radio hop
   • IP routing required to achieve transitivity/forwarding
   • Dave Thaler - this IS a multi-link subnet; same model as the Autoconf link-model, so there may be a common solution
   • Zach Shelby - from Dublin talked to Autoconf and other groups, tried to develop a model that is not a multi-link, but 4861 and non-transitivity means the link badly serves the subnet
   • Dave Thaler - try to reuse text or have a common doc, avoid pitfalls of multi-link subnet; may go both ways
   • Ralph Droms - the Route Over link-model (see pix slide 7 in presentation) does not look like a single subnet - multiple routers
   • Carsten - there is a shared prefix
   • Christian Vogt - are they routers?
   • Zach - Yes, but forwarding within one prefix
   • Carsten - nodes in the sea of nodes live in one prefix, the routing protocol ensures packets arrive; terminology may be the problem
   • Dave T - this may be a multi-hop subnet or as in autoconf model all are off-link (no subnet); remove the blue circle and say the red circle is not useable.
   • Zach - change the model
   • Fred Templin - when you have hosts don't you need on-link subnet? Dave - no
   • Single LoWPAN - one edge router to backhaul; extended LoWPAN has multiple edge routers (coordinating on prefix).
   • Ad-hoc - one node plays the role of an edge router, generates ULA
   • Whiteboard Model - binding between the address and the Owner Interface ID; softstate (refresh required)
   • Node sends Node Registration towards ER, ER performs DAD; DAD is not discussed
   • Carsten - get back to it later in presentation
   • Using Router Advertisement, with relay from 6loWPAN routers to ER
   • Duplicate Identifier Detection - is it the same node moving or a new node? EUI-64 may be duplicated, so add a 32 bit nonce. (see table slide 17) not part of DAD
   • RA Options - look the same as 4861, but also a compressed 6loWPAN option (6IO and 6SO)
   • Node Registration and Node Confirmation messages (slide 20) include owner nonce; also Address Option (6AO)
   • Doc is not long, but includes lots more explanatory. Looking for review/input from 6man group
   • Suresh Krishnan - on slide 16 what happens when backbone link is down (NR cannot be translated into NS/NA to be distributed to other ERs)
   • Dave T. - DAD does not cover highly dynamic cases; if nodes are moving around, there needs to be partition
   • Carsten - the backbone is the stable part
   • Suresh - does the node need to see the NC before using the address? Yes
   • Bob Hinden - definitely need input from 6man; avoid multitude of ND variations, we should look for commonalities with other link types
5. Next Steps on IPv6 Address Selection,
   • Documents :
     • draft-chown-addr-select-considerations-03.txt
     • draft-arifumi-6man-addr-select-conflict-01.txt
     • draft-arifumi-6man-rfc3484-revise-02.txt
   • Presenter : Arifumi Matsumoto
   • Address Selection Design Team started at IETF 72 - define dynamic update of RFC 3484 policy table
   • RFC 5220 scenarios - drivers for policy change; characterized into several categories (Internal, external)
   • How dynamic are the updates? Not frequent except multi-home TE
   • No radical changes to RFC 3484, but some issues and minor changes of default behavior; reflect changes already in some OSs (update draft)
   • Differing admin domains - multiple interfaces lead to inadvertent multiple policies on host (address-select-conflict draft)
   • Hui Deng - several meetings back clarified goals, need to coordinate with MEXT WG on site multihoming versus host multihoming
   • Arifumi - coordination is good; need to clarify; while focused on site multihoming, need to consider accidental host multihoming cases; this is more for stationary hosts
   • Hui - home router may multiple admin domains
   • Bob Hinden - please discuss this on the list - this is a substantial discussion
   • Suresh - this is different than the MEXT use cases
   • Bob, Hui - the draft should clarify this
   • Source and Destaddr policies conflict - host/site coordinates with routing
   • Next Step - how to deliver the policy
     1. RA
     2. DHCP
     3. mechanism like a routing protocol
   • Jinmei - scheduled RA?
   • Looking for inputs and review to get WGLC, secondary drafts not widely reviewed yet.
   • Dave Thaler - RA vs DHCPv6 see IAB host configuration principles document - better to have a single method; may be better to take up with DHC to fix the deficiency to use that mechanism; not obvious that the router has to have this information - let's not have two different mechanisms
   • Suresh - policy change vs routing change that trigger policy update, different use cases
   • Tony Hain - issue with IAB doc - can't do squat without having both RA and DHCP
   • Bob Hinden - let's table that and
   • Tina Tsou - how does the policy server inject the change?
   • Policy server could be a router or DHCPv6 server
   • Tina - what are the conditions that trigger the change?
   • Bob - continue on list
6. IPv6 Neighbor Cache Update,
   • Document : draft-kitamura-ipv6-neighbor-cache-update-00.txt
   • Presenter : Hiroshi Kitamura
   • Background - addresses that frequently change from "used" to "not used"
   • Lengthy Neighbor Cache retention even after the client is gone; not garbage collected until stale for a long time (24 hours)
   • Not good from resource management (addresses cannot be reused) and some security concern
   • Manners - clean up when you go - when an address is no longer to be used, notify to clean up
   • Heuristic - using special NS message to trigger Delay/Probe states so cleaned up
   • Explicit - modify NA message with extended flags to say delete;
   • Two can be combined to cover nodes that do/not understand the extensions; either way surely deleted
   • Both individual and combined methods have been implemented; authors recommend the combined type
   • Jinmei - should the client send a message before going to sleep? What is the security concern in the problem statement?
   • Dave Thaler - not sure what the problem is, garbage collection and cache flushing should be sufficient; there are advantages of caching for temporary "sleep" to avoid overhead. Not convinced this is necessary
   • Erik Kline - same thoughts. Allows an attacker to disable address by forging the NA.
   • Tobias Gondrom - not sure of the benefit; more risk introduced by explicit deletion than persistence;
   • Bob Hinden - please discuss on the list
7. Use of /127 IPv6 Prefix Length on P2P Links Not Considered Harmful,
   • Document : draft-kohno-ipv6-prefixlen-p2p-00.txt
   • Presenter : Miya Kohno
   • /127 was considered harmful, conflict with subnet-router anycast. But this is not useful nor widely deployed
   • There are 4 ways to avoid pingpong issues, including using /127 for p2p links
   • With /127 Interface IDs are simple, conserves space, avoids "darknet"
   • Goal of draft - allow operators to use /127 on link types where it makes sense
   • It may be safer to disable ND and SLAAC when not needed
   • Useful comments from Lorenzo and Jinmei, to be addressed in update
   • Jinmei - not sure for the rationale
   • Randy Bush - note: operationally we are running /126; is this better? Let's not worry about the /64 argument
   • Dave Thaler - I still think /127 is harmful, but can be used in a way that is not so harmful. What you want to do is use the off-link model - no subnet, no ND, prefix length is irrelevant.
   • Remi Despres - interesting, related to protecting U/G bits in prefix. Discuss further
   • Seiichi Kawamura - rationale and choices; I lean towards using /127 but need to understand Dave's comment
   • Christopher Liljenstolpe - not looking at /64, but /127 or /126 but not fond of link-local
   • Suresh - generally like this idea; this doc should say if you use /127 MUST NOT configure subnet-router anycast
   • Jared Mauch - /126 in our network, clever workarounds are needed to avoid ping-pong problems.
   • Bob Hinden - general interest, issues to discuss, not ready to adopt
8. Node Requirements Update
   • Document : draft-ietf-6man-node-req-bis-03.txt
   • Presenter : Ed Jankiewicz
   • No update before the meeting, editors are working on a revision to be issued soon
9. The IPv6 UDP Checksum Considerations
   • Document : draft-fairhurst-tsvwg-6man-udpzero-00.txt
   • Presenter : Magnus Westerlund
   • Proposal - turning off UDP checksum, at least for outer header in tunnels
   • AMT gateway with UDP - substantial amounts of data, some routers don't have access to the complete packet.
   • LISP - ECMP
   • Commonality - both tunneling mechanisms that don't need UDP checksum
   • RFC 2460 states UDP checksum is not optional, should log error and drop packet with zero checksum; this was an IPv6 design choice
   • Greg Shepherd - what is the reason for the IPv6 design choice?
   • Let the end-host verify to lighten the load on the routers
   • Firewalls may block UDP with zero checksum due to RFC 2460 violation
   • Turning off in some OSes may not be possible
   • Margaret - lots of routers have checksum offloading
   • For tunnel traffic, zero checksum has low impact; corruption of outer IPv6 header does matter; if host turns off UDP checksum, loses protection from corrupted header
   • Remi - turn off as receiver or sender? maybe as an option the receive can choose to ignore
   • Margaret - it needs to be coordinated - if someone is allowed to send zero, the receiver needs to ignore; MUST/MAY... otherwise creates black holes
   • Randy Bush - don't we already know how to do zero checksums (IPv4)
   • The header protection is not present in IPv6
   • Randy - all vendors seem to do zero checksum with IPv6; why are we doing something different again?
   • Joe Touch - assumed the links had protection, and transport provided end to end. If using UDP as a transport and turn it off, it's like turning off Ethernet checksum. I don't see it as expensive
   • Margaret - expense of checksum is diverting routed traffic from hardware offset
   • Remi - strong relationship with fragmentation
   • Joe Touch - anytime you copy a packet, checksum is noise. Long term protocol change for short term hardware deficiency not a good idea
   • Albert Chen - link-layer vs end-to-end - on tunnel link (intermediate) is not so important, there is still end-to-end checking
   • Christopher L - operators should not have to dig into packets
   • Margaret - want to use UDP but can't afford checksum; UDP header for load balancing advantage over IP-in-IP. Source Port ends up being a hash. UDP-lite would do this, but load balancers don't understand. Do we want to do something else to solve the load balancing problem? Low end CPE checksum offloading, routers, ECMP/LAG - all making different assumptions.
   • Greg Shepherd - pull out of IPv6 forwarding, now we have applications that want to push this back in.
   • Bob Hinden - consequences were considered, including adding a checksum to UDP
   • Joe Touch - I would like a list of routers that don’t know where the checksum is
   • Randy Bush - Jumbo frames stretches the Ethernet checksum algorithm. Don't have a good measurement of the induced errors
   • Joe Touch - maybe only ok if inner packet is IPv6.
   • Marshall Eubanks - LISP can send IPv4 w/o checksum in IPv6 w/o checksum; AMT can also do - then no protection
   • Dino - ignore on receipt
   • Propose NOT to make checksum rule change
   • Marshall - ATT labs AMT rolling out experimentally, can we ask them to try this;
   • Bob - real data would be great
   • Tina - if this is only for ECMP can we use this for other purposes?
   • Margaret - should update flow label - shouldn't be used as the ONLY source for routing decisions, need to clarify
   • Continue on the list - and get together face-to-face