Minutes for 6MAN at IETF-91
minutes-91-6man-1

6MAN Working Group - Honolulu IETF Meeting

Friday, 0900-1130, 14 November 2014, Coral 3
Chairs: Bob Hinden, Ole Troan

Minute taker: Pascal Thubert 
Jabber Scribe: Andrew Yourtchenko

Jabber Room: 6man@jabber.ietf.org 
Meetecho: http://www.meetecho.com/ietf91/6man

Slides can be found at: http://www.ietf.org/proceedings/91/6man.html

-----------------------------------------------------------------------
Agenda
-----------------------------------------------------------------------

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

Working Group Drafts

   Efficient ND Design Team, Status Repot, Erik Nordmark, 20 min.
   
   Recommendation on Stable IPv6 Interface Identifiers,
   draft-ietf-6man-default-iids-01.txt , Fernando Gont, 10 min.

Active Individual Drafts

   Deprecating the Generation of IPv6 Atomic Fragments,
   draft-gont-6man-deprecate-atomfrag-generation-01 , Fernando Gont,
   15 min.

   Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO),
   draft-skeen-6man-ipv6geo-01.txt , Brian Skeen, 15 min.  

   The IPv6 Flow Label within a LLN domain
   draft-thubert-6man-flow-label-for-rpl-05.txt , Pascal Thubert, 15 min.

   IPv6 Prefix Length Recommendation for Forwarding,
   draft-boucadair-6man-prefix-routing-reco-03.txt , Alex Petrescu, 10
   min.

   Validation of IPv6 Neighbor Discovery Options,
   draft-gont-6man-nd-opt-validation-01.txt , Ron Bonica, 10 min.

   Overview of Source Address Dependent Routing,
   draft-sarikaya-6man-sadr-overview-02.txt,
   draft-sarikaya-6man-next-hop-ra-02.txt,
   draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00.txt, Bechet Sarikaya, 10 min.

   IPv6 Segment Routing Header (SRH),
   draft-previdi-6man-segment-routing-header-03.txt,
   draft-vyncke-6man-segment-routing-security-00.txt , Eric Vyncke, 10 min.

New Individual Drafts

   CGA SEC Option for Secure Neighbor Discovery Protocol,
   draft-jiang-6man-cga-sec-option-00.txt , Dacheng Zhang, 5 min.

   CGA Security Improvement, draft-rafiee-rfc3972-bis-00 , Hosnieh Rafiee, 5 min.

   IPv6 Flow Label Reflection, draft-wang-6man-flow-label-reflection ,
   Sheng Jiang, 5 min.

   IPv6 ND Option for Network Management Server Discovery,
   draft-liu-6man-nd-nms-discovery-00.txt , Bing Liu, 5 min.

   Transmission and Processing of IPv6 Options,
   draft-gont-6man-ipv6-opt-transmit-00.txt , Fernando Gont, 5 min.


Introduction, Agenda Bashing, Document Status,  Chairs, 15 min.
------------------------------------------------------------------------------------------

Chairs provide document status
3 adoption calls, plus one in queue (see slides)
Asking for comments, none from the room.

Working Group Drafts
------------------------------------

Efficient ND Design Team, Status Report, Erik Nordmark, 20 min.
----------------------------------------------------------------------------------------------

History of DT since London IETF 89

About sub-optimality in IPv6 ND, discussed potential problem areas and
operational techniques to make things better.  Measurement results in 2
drafts (see slides). reported to 6ops.  Erik lists areas of concerns:

  - ND multicast in general
  - DAD

There are places where existing ND works well, so we should not be
disrupting that.  There is a range of behaviors for (duty cycled)
sleeping devices, e.g. wake on packet vs. periodic schedule.  In some
cases, ND is a very small piece of the problem (e.g. vs. multicast DNS).
RS does not seem to be an issue. Easily filtered since sent to all
routers, not sent on Wi-Fi usually.  multicast RA is more of a problem.

Also, a draft about cellular indicates that unsolicited RAs may cause
explosion of paging in the network (1M host) to find the target before
the RA is delivered.  NS/NA can be alleviated with L=0 (not on-link),
sleep proxies may cause unsolicited NA in case of MAC address transfer.
New draft on DAD issues to consider if we are to do something different.
DAD is unreliable? how reliable should it be ?

What about link split  / rejoin ?

Already docs on operational technique to reduce though implicit or
explicit filtering.  e.g. splitting the L2 domain if the expectation is
to reach the outside as opposed to operate on link local.  ComCast
appears to deploy handing out a /64 per user in stadiums (no actual doc
here).  RS/RA improvements: change the max allowed limit. Apparently it
is deployed already.  Solicited RAs should e answered unicast.

Allow to flip the model so that the host indicates that it will poll the
router as opposed to wait for unsolicited and randomize the reqs.
Support by hosts and routers can be signaled so the operator sets up
policies. Duty cycled host may see different behavior when waking up
before next RS polling time, if it missed RAs that deprecated stuff and
may wait to the next polling time to learn again.

DAD side: what about the list of 11+ problems?  DT talked about
solutions, snooping or registration DAD choices, see slides.

Pascal Thubert indicates that explicit registration is useful
vs. implicit because hard to discover misses.

Michael Abrahamsson: need to improve multicast either here or at
IEEE. Should the IETF collect information to help IEEE address it?

Erik: It is not only multicast, e.g. sometimes the spanning tree is not
up yet and the host cannot tell. Also network split and merge.

Dave Thaler: supports RS refresh. Same problem in NBMA as in Wi-Fi. A
generic version of the NBLA work could be useful. in Windows, the
implementation is over-foo agnostic.

Fred Templin: liveliness is important

xxx: 2 issues.  RA interval mobile IP depends on short interval.  need to
clarify why DAD, role of DAD.

Lorenzo C.: will force to change implementations which do not forward
unless they see a DAD, and that will be a good thing.

Erik: Q1 is whether we do something or nothing

Lorenzo C.: a number of the 14 issues are already solved


Recommendation on Stable IPv6 Interface Identifiers,
draft-ietf-6man-default-iids-01.txt , Fernando Gont, 10 min. 
-----------------------------------------------------------

Intro to the doc, about IPv6 over foo recommends using 7217.  Reviews
from Ralph Droms and Carsten Bormann.  See slides for issues.

Alexandru Petrescu agrees with Dave Thaler because the IID can help debug
a network

Kerry Linn: a single MUST in Dave's text seems to force all nodes.

Dave Thaler: first MUST is for any foo <sorry Dave is too fast for my
typing>.  Dave accepts that the last SHOULD can be an update by
reflashing the device, and it is a SHOULD anyway.

Alyssa Cooper: response to Kerry: Dave's sentence could be clearer in the
subject. Goal would be to narrowly define when the recommendation
applies.

Juan Carlos Zuniga: text too ambiguous. Exceptions should be explicit. If
privacy is our recommendation then then the SHOULD would be about when it
is disabled, there SHOULD be a good reason why.

Lorenzo: L2 privacy should apply to all addresses.

Fernando: example of mail servers on link (e.g. found by bonjour) can
leak a link local address. Discussion already happened in London for this
doc

Erik Nordmark: doc is silent about applicability to link local, that
should be explicit. Is it worth pointing out that we would link
underlying technology to provide privacy.

Randy Turner: Does define mean implement?

Dave Thaler: only 3rd sentence is about implementation. 

Samita: agree we need to change for IPv6 over foo. But why is the first
sentence a MUST instead of a SHOULD. Else there is a need for
clarification. Do we need the MAY sentence.

Jen Linkova: seems that the cost is put on properly configured
networks. Desire to connect to devices that are known by mac
address. Desire to have a permanent stable address.

X: Not so much privacy but not leaking

Pascal: Need to loosely couple the L2 and L3 privacy addresses,
properties may be different. E.g. lifetime, or trigger to renew.

Bob suggests to move on and follow up on mailing list.


Active Individual Drafts
-------------------------------

Deprecating the Generation of IPv6 Atomic Fragments,
draft-gont-6man-deprecate-atomfrag-generation-01 , Fernando Gont, 15 min.
---------------------------------------------------------------------

Stateless IP/ICMP Translation Algorithm (SIIT) 

IPv4 frag ID is only 16 bits and at decent rate is not reliable.
Fernando describes attacks.

Suresh K: Slippery slope. Point solution for one issue of atomic
frags. What about forge PTB for other size like 1281 bytes packets. I
accept problem is real. we should either deprecate frags or not do
anything.

Andrew Yourtchenko: Fix should be in TCP. 

Fred Templin: in MANET we need atomic fragments. Can't broadly deprecate
them.

Erik N.: supports simplification in the spec. We could day it's OK for
firewall to filter atomic frags that should not cross certain boundaries.

Ron Bonica: Valid problem. Amplify Suresh's point. Need to consider
deprecating frags.

Eric Kline: Should be able to write a stack that only sends up to 1280.

Suresh K.: summary of stack behavior very useful

Jen Linkova: seems that we are fixing what's easy to fix as opposed to
the real problem?

Ole: difference between removing the words in 2460 and banning atomic
fragments completely

No consensus to move forward at this time.  Work will continue on the
 mailing list.


Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO),
draft-skeen-6man-ipv6geo-01.txt , Brian Skeen, 15 min.
---------------------------------------------------------------------

Meetecho blocked by corporate firewall so Fred does talk on behalf.
reading slides. Fred describes aircrafts use case. Links vary and not all
have Link layer geo info. Ipv6 the only common layer.

Martin Thomson: this is a geopriv issue. Challenging that IPv6 is the
only thing in common. All the upper layers are in common. If you need to
tell someone where you are is go and tell them.

Lorenzo C.: tech comment what about lying about location. What this tells
is we need vendor option space since on the overall internet it would be
a privacy issue and insane to support.  Better strategy should be to ask
for vendor space to do stuff in the privacy of my own network

Fred Templin: I want interop

Lorenzo: yes, writing an informational

xxx: supporting vendor option. Lots exist at app layer which solve all
issues including privacy.Draft should focus on hard case when the L3
approach is the only possible.

Fred: yes, this is for private network use but need interoperable
implementation.

Alex Petrescu: Geo has more precise nature. Privacy: is the destination
option protected by ESP

Fred T.: can be and if so privacy is addressed

Martin Thomson: need to indicate that it has to be between consenting
peers. Geopriv facilitates that sort of things, thats the key. A lot of
redundancy with geopriv.

James Woodyatt: happy of genuine use case for geopriv data. real value
for informational. Unsure about WG doc. Probably overkill for a whole
dest option code. Maybe not vendor but maybe more general purpose than
this

Fred T.: concerned about safety. Want to speak the same information

Igor Gashinsky: Iphone beaconing my location is terrifying. The kernel is
the right place to decide privacy. Support vendor org or private thing
that could be filtered.  too close to shoot yourself in the foot. must be
more difficult for people to use

Andrew Y.: please mandate encryption.

Richard Barnes: filtered at the routers.

Ole T.: we try to put IPv6 end to end

Bob:  Continue the discussion on the mailing list.


The IPv6 Flow Label within a LLN domain
draft-thubert-6man-flow-label-for-rpl-05.txt , Pascal Thubert, 15 min.
----------------------------------------------------------------

(Pascal: since I'm the note taker not many notes there)

Brian Carpenter expressed support, 

Lorenzo indicates that the zero flow label could be obtained by
configuration since it is a single admin domain

Brian Haberman expressed concern on how much we open this but then as
long as it is contained in a domain.


IPv6 Prefix Length Recommendation for Forwarding,
draft-boucadair-6man-prefix-routing-reco-03.txt , Alex Petrescu, 10 min.
-----------------------------------------------------------------

Igor Gashinsky: MUST NOT seems pretty strong

Lorenzo C. : some vendors do not support some sizes. Should recommend
practices. Shy away from changing size of IID.

Ole T. : unclear what 6MAN spec should be updated

Lorenzo C.: v6ops can clarify, 6MAN has been working like that forever
since forwarding is not related to IID length.

Fernando G. This is a clarification so it belongs to 6MAN

Lee Howard: We would not kick it off.

Result of the discussion was to see if V6OPS would take this document on
as it does not change any IPv6 specification, but make an implementation
recommendation.


Validation of IPv6 Neighbor Discovery Options,
draft-gont-6man-nd-opt-validation-01.txt , Ron Bonica, 10 min.
--------------------------------------------------------------------------

Chairs asked for a show of hands of whom had read it.  Not many people in
the room had read the draft.  The chairs will do an adoption call on the
list.


Overview of Source Address Dependent Routing,
draft-sarikaya-6man-sadr-overview-02.txt,
draft-sarikaya-6man-next-hop-ra-02.txt,
draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00.txt, Bechet Sarikaya, 10 min.
-----------------------------------------------------------------------

(No notes)


IPv6 Segment Routing Header (SRH),
draft-previdi-6man-segment-routing-header-03.txt,
draft-vyncke-6man-segment-routing-security-00.txt , Eric Vyncke, 10 min.
-----------------------------------------------------------------------------

(No notes)


-----------------------------------------------------------------------
Meeting adjourned
-----------------------------------------------------------------------

There was no time to present any drafts in the “New Individual Drafts” section.

New Individual Drafts
------------------------------

CGA SEC Option for Secure Neighbor Discovery Protocol,
draft-jiang-6man-cga-sec-option-00.txt , Dacheng Zhang, 5 min.

CGA Security Improvement, draft-rafiee-rfc3972-bis-00 , Hosnieh Rafiee, 5
min.

IPv6 Flow Label Reflection, draft-wang-6man-flow-label-reflection , Sheng
Jiang, 5 min.

IPv6 ND Option for Network Management Server Discovery,
draft-liu-6man-nd-nms-discovery-00.txt , Bing Liu, 5 min.

Transmission and Processing of IPv6 Options,
draft-gont-6man-ipv6-opt-transmit-00.txt , Fernando Gont, 5 min.