6man Meeting Minutes
IETF78

July 27 & 28, 2010

Maastricht, Netherlands

Bob Hinden, Brian Haberman, chairs

Ed Jankiewicz, minute taker
Marshall Eubanks, jabber scribe

---------------------------------------------------------------------

Agenda

 Tuesday, July 27, 2010, 1710-1810 Afternoon Session III, Auditorium 1

   Introduction, Agenda Bashing, Document Status, Chairs, 10 min.  

   Node Requirements Update, Thomas Narten, 20 min.
     draft-ietf-6man-node-req-bis-05.txt

   IPv6 Address Selection, Arifumi Matsumoto, 20 min.
     draft-ietf-6man-addr-select-considerations-02.txt
     draft-arifumi-6man-rfc3484-revise-03.txt

   Use of /127 IPv6 Prefix Length on P2P Links Not Considered Harmful, Miya
   Kohno, 10 min.
     draft-kohno-ipv6-prefixlen-p2p-02_draft3.txt 


 Wednesday, July 28, 2010, 1030-1130 Morning Session II, Auditorium 2

   The IPv6 UDP Checksum Considerations, Gorry Fairhurst, 15 min.
      draft-ietf-6man-udpzero-00.txt 

   Flow Label Update, Shane Amante, 10 min.
      draft-carpenter-6man-flow-update-03.txt 

   Using the IPv6 flow label for equal cost multipath routing and link
   aggregation in tunnels, Shane Amante, 10 min.
      draft-carpenter-flow-ecmp-02.txt

   An IPv6 Routing Header for Source Routes with RPL, Jonathan Hui, JP
   Vasseur, 10 min.
      draft-hui-6man-rpl-routing-header-02.txt

   RPL Option for Carrying RPL Information in Data-Plane Datagrams, Jonathan
   Hui, JP Vasseur, 10 min.
      draft-hui-6man-rpl-option-01.txt

-----------------------------------------------------------------------
 Tuesday, July 27, 2010, 1710-1810 Afternoon Session III, Auditorium 1
-----------------------------------------------------------------------

Introduction, Agenda Bashing, Document Status, Chairs, 10 min. 

There were three talks that we didn't have room for on the agenda.
Please review the following drafts and comment on the mailing list:

   draft-axu-addr-sel
   draft-chaparadza-6man-igcp
   draft-yong-6man-large-flow-classification

Document Status

   Uniform format for IPv6 Extension Headers
      InitialWG draft published
   IPv6 Subnet Model
      Published as RFC5942
   IANA Routing Header
      Published as RFC5871
   Canonical Address Format
      RFC Editor's Queue
   RA Option for DNS
      IESG Evaluation - AD Follow-up


Node Requirements Update, draft-ietf-6man-node-req-bis-05.txt , Thomas
Narten, 20 min.
----------------------------------------------------------------------------

Simple editorial changes, e.g. Security Section virtually non-applicable,
see individual documents advice, guidance, e.g. RA vs DHCP

Net Operator controls what actually supplies configuration client device
may or may not have control of where/how deployed RA - best for info same
at all nodes but DHCP - client specific implement both for flexibility

DNS config - option in RA as well as DHCP SHOULD implement DHCP for
"other" info e.g. RA vs DHCP Net Operator controls what actually supplies
configuration client device may or may not have control of where/how
deployed RA - best for info same at all nodes but DHCP - client specific
implement both for flexibility

DNS config - option in RA as well as DHCP
SHOULD implement DHCP for "other" info, and if you do, you can use it for DNS
SHOULD implement DNS RA - can't say must, not every router supports 

Context

Dave Thaler - implement both applies as well to operator, given current
state.  If the operator always chooses both, what if client receives
conflicting information?
Thomas - not a new problem, should it be addressed here or maybe MIF?
Dave - call out an issue even without a solution
Bob Hinden - align with DNS RA Option text on this subject
Jari - agree with Dave mostly.  Operator outside scope, but routers are
in scope.  I have both on my IPv6 network
Thomas - as an implementer both should be implemented
Jari - for merging between RA and DHCP, see the RA option
? - complaints from customers if client does not support the option you
choose.  Should this recommendation be in Node Requirements or a separate
draft?
Suresh - MUST for DNS RA on router?
Thomas - yes on poll
Dave - routers almost MUST do both, hosts SHOULD/MUST do one or the
other, not necessarily both
Thomas - poll the list

Address Config - retain MUST for SLAAC, elevate MAY to SHOULD on DHCP

What about IPsec and IKEv2?  IPsec is a MUST, IKEv2 only says SHOULD, but
is a MUST in the security architecture.  IPsec alone without IKE is not
enough;

Tina - differentiate by device SHOULD or MUST.
Ed - see profiles text on product class
Dave - if you MUST be secure, then you SHOULD do IKEv2
Hui - special nodes, is this too strong, propose downgrade to MAY.
Thomas - take SHOULD at its definition, sort of MUST unless you have good
reason not to
Eric Vyncke - dynamic key negotiation is a MUST, for example IKEv2, but
there are others.
Thomas - for interoperability, multiple solutions not a good idea
? - internet of things - constrained devices
Jari - SHOULD implement IPsec and IKEv2; can't dictate
Thomas - some single purpose appliances may have other security devices
General and broad recommendations for a wide class of products.  bad
story on M&O bits in DHCP/ND - needs to be fixed but not in this doc
? mobility, conditionals - can we cite RFC 3963 on mobile routers
Thomas - any optional facility as a MAY


IPv6 Address Selection,
draft-ietf-6man-addr-select-considerations-02.txt,
draft-arifumi-6man-rfc3484-revise-03.txt , Arifumi Matsumoto, 20 min.
----------------------------------------------------------------------

Recent changes in addr-select-considerations
how do you deal with conflicting policies?  Can't standardize
Arifumi draft on address selection conflict
DHCP is better in management, RA better with routing
3484-revise draft addresses problems that need to be fixed
Are these ready for WG adoption from Design Team?  Are we close to
consensus with the working group, the DT has consensus.
Ed - 3484-revise flow into a 3484bis?  Yes.  
Brian - consensus is to adopt 3484-revise as WG doc
Brian - what about draft-fujisaki-dhc-addr-selection-opt?  DHC is one way
to do this, but needs discussion on the WG list.
Tony - DT is ready to hand off several docs to the WG for continuation
Dave Thaler - support adopting 3484-revise, significant work and some
things I don't agree with.  Bring it to the group.  More on the list.


Use of /127 IPv6 Prefix Length on P2P Links Not Considered Harmful,
draft-kohno-ipv6-prefixlen-p2p-02_draft3.txt , Miya Kohno, 10 min.
----------------------------------------------------------------------

interrouter p2p links, no autoconfig - numbered addressing used; any interface 

/127 is already operational practice, like /31 in IPv4.  Simple solution for some vulnerabilities
was regarded as harmful, in conflict with subnet-router anycast; this is not realistic concern

MUST be supported, MAY be assigned in 4291 need to relax the prohibition,
but indicate that if 1-bit interface ID is used, subnet-router anycast
MUST be disabled.

Joel Halpern - can't change the title of a published RFC; publish a revision
Dave - subnet-router anycast can be sent by anyone in the internet.  You
have to disable it for the /64 portion of the /127
Randy Bush - yes you are correct, there can be more than one router.  No
damage if someone sends to that anycast
Dave - mtrace, reply to someone else; you must disable across everything
in the /64
Dave - individual addresses on an offlink model, not a prefix.  That does
not impact other docs
Randy - I don't see a problem with what Dave is saying, requires more
discussion.
Bob - some things make me uncomfortable, draft needs to be updated,
discussed on the mailing list
Alexsi - recommendations slide - like the concept of the draft, need more
convincing that every router with p2p links MUST support this
Thomas - apparently have routers today where this is not possible, and
they want to.  Not hard in any particular router configuration
Alexsi - consumer routers don't need to do this
?Level-3 - arguing over wording/phrasing shows it's important, we should
do it.
Tatyuna - RFC 4291 recommendation is operational, not architectural,
seems awkward
Dave - which thing are we talking about?
Brian - publish the draft that missed the cutoff, then I will call for
adoption on the list
Randy - arbitrary /127 on any p2p link, vendors are resisting by pointing
to the prohibition
Jan - pragmatically, lots of products already support /127.  This seems
heavy in terms of requirements

--------------------------------------------------------------------
Wednesday, July 28, 2010, 1030-1130 Morning Session II, Auditorium 2
--------------------------------------------------------------------

The IPv6 UDP Checksum Considerations, Gorry Fairhurst, 15 min.
  draft-ietf-6man-udpzero-00.txt 
-------------------------------------------------------------


Do we want to allow zero checksum?
ready to submit an updated draft, not ready to say what the WG next steps
are pros and cons of zero checksum, caveats and rules for use
What will middleboxes do with a checksum of zero in IPv6?  To the group,
if you know or have opinions please speak up.  is ECMP a need?
What we need to do to sanction this?
verify integrity of inner packet
how do we expect nodes to handle?
nodes by default MUST use original behavior unless they explicitly call
API to allow zero-checksum
API SHOULD NOT wild-card the source (is this OK)
Jari - this is from a single node perspective, but peer behavior is
important - do we need to negotiate this?  Gorry - yes, but don't know
how yet.  Jari - most tunneling protocols are OK with this.  Gorry -
since you can't wild-card
Stig - number 8 not necessarily universal
Joel Halpern - the receivers don't know who the senders may be and can't
know who will be using zero checksum
Marshall - LISP or AMT not receiving from any sender, but a LISP or AMT
sender.
Gorry - don't know the protocol in these cases, not in the protocol
field.
Marshall - specifically formatted LISP traffic; could enforce a check in
LISP.
Gorry - has does a receiver know it's a LISP?
Joel - either the receiver is LISP and happy, or not and drops; most
applications will validate before accepting
Alexsi - UDP is stateless; detecting endpoint support construes state of
sender.
Gorry - how do we differentiate whether the packet got to the right
receiver
Alexsi - UDP is transport, not a tunnel.  Tunneling should be done with
an appropriate mechanism
Marshall - the protocols that need this can't get this on the Internet
today;
Alexsi - Ipv6 won't work on the internet today either
Shane Amonte - the reason for using UDP encap is routers don't have
mechanism to extract a fine grained 5-tuple for load balancing.  Flow
label not well defined.
Alexis - flow label should be better defined and used NAT traversal and
firewall also impedes UPD-lite need feedback on the list to this
particular draft; rules, issues and caveats; do we want to allow this?
Brian - the solution draft also has not gotten a lot of response either
Marshall - unfair to say we haven't been pushing the other doc,
purposeful to work through this draft first, deciding whether to go
through with it and push the other.
Jari - no just AMT and LISP.  Widely deployed protocols 
Marc Townsley - LNSes will not appreciate doing checksums


Flow Label Update, Shane Amante, 10 min.
  draft-carpenter-6man-flow-update-03.txt 
---------------------------------------------

Update to the IPv6 flow level specification

vague in several areas, not widely implemented in -00 draft, proposed MSB
of flow label to signal semantics - e2e or locally defined

Flow label largely unused by hosts and routers, no integrity on
flow-label - Ipsec considers it mutable.  fixed location - can be used in
hardware for load distribution potential conclusion - operationally
challenging to restore/reset FL at domain ingress/exit either require e2e
immutable, strengthen RFC 3697 OR allow mutable FL, eliminating use cases
depending on immutability

Publish informational?  Let existing RFCs continue as is.  OR choose
between e2e and mutable and define properly

Fred Baker - how do you want to use it in load balancing?
Shane - Hash value could be stored in the FL.  Core routers could use the
FL in load balancing.
Fred - FL was to support Nimrod router architecture, but became useless
when made immutable
Tony Hain - disagree with Fred - taking RSVP out from under it made it
useless.  This is not the right approach.  Why isn't the Traffic Class
field adequate?
Joel - not for the same thing (but similar properties)
Shane - not enough granularity
Tony - document why
Mark - not putting hash in DCSP
Shane - 2**10 or 11 - traffic class is not big enough.  Distinguish three
classes of traffic - control, Best Effort and VoIP.  The intent is FL
stateless allowing simple way to input hash rather than next header
Joel - as currently presented, mutability is nice, but need specification
of how this all works
Philip Matthews - behave working on translation which specs setting FL to
zero ? 12 bits for this, leave 8 bits for applications, some applications
already depend on flow label Flow label as a nonce has benefit
? protect against PMTUD attack
Chris Donelly - voice flow
Alexis - relying on end node to create FL, trust issue
Shane - agree
Quick poll:  8 Option 1, 8 Option 2, 1 do nothing


Using the IPv6 flow label for equal cost multipath routing and link
aggregation in tunnels, Shane Amante, 10 min.
   draft-carpenter-flow-ecmp-02.txt
--------------------------------------------------------------------

source tunnel end point sets flow label in outer packet, for load balancing

call on the list regarding WG adoption


An IPv6 Routing Header for Source Routes with RPL, Jonathan Hui, JP
Vasseur, 10 min.
   draft-hui-6man-rpl-routing-header-02.txt
-----------------------------------------------------------------------

ROLL WG  routing on low-power and lossy networks

detect inconsistencies when routing

hop by hop option, useful to RPL routers

consensus to adopt as WG item

RPL option payload

node's location in topology, where the packet is moving, conclude on
consistency


RPL Option for Carrying RPL Information in Data-Plane Datagrams, Jonathan
Hui, JP Vasseur, 10 min.
   draft-hui-6man-rpl-option-01.txt
----------------------------------------------------------------------------

Routing Header for Source Routes

route across limited memory routers, rendezvous points

common prefix across RPL domain

constraints to avoid RH0 concerns; no loose source route, verify no loops

New ICMP dest unreach error when strict source route fails

Comments on both drafts:
Suresh - options draft; don't understand drop; should send ICMP error
Bob Hinden - not inserting the RH on the fly, using encapsulation; sort
of like RH4
Jari - concern with both encap and insertion, two different formats to
support;
Jonathon - not both at the same time
Jari - more code; lower parts of the stack that may not work in some
networks
Bob - easier than having to move stuff around in the headers.
Eric Nordmark - if both are in the RPL domain no need to encap, depends
what you want to build.  Can avoid doing both.
Alex Petrescu - any thought on security?  Will the RH be protected by AH
or TBD mechanism.
Jonathan - RPL specific
Brian - comment on the list.  Plenty to chew on.


---------------------------------------------
Meeting Adjourned
---------------------------------------------