Minutes IETF100: 6man
minutes-100-6man-00

6MAN Working Group - Singapore IETF Meeting
Tuesday, 14 November 2017, 13:30-15:30, Canning
Chairs: Bob Hinden, Ole Troan

Minute taker: Victor Kuarsingh
Jabber Scribe: Mikael Abrahamsson

Jabber Room: 6man@jabber.ietf.org 
Meetecho: https://www.meetecho.com/ietf100/6man

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

Agenda

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

NAT64 Experiment, Jen Linkova

IPv6 Node Requirements, draft-ietf-6man-rfc6434-bis , Tim Chown, 30 min. 

IPv6 ND PIO Flags IANA Considerations, draft-troan-6man-ndpioiana , Ole
Troan, 10 min. 

Recommendations on the Filtering of IPv6 Packets Containing IPv6
Extension Headers, draft-ietf-opsec-ipv6-eh-filtering , Ron Bonica, 15
min. 

Recommendation on Temporary IPv6 Interface Identifiers,
draft-gont-6man-non-stable-iids , Fernando Gont, 15 min. 

IPv6 Address Usage Recommendations,
draft-gont-6man-address-usage-recommendations, Fernando Gont, 15 min.  

Route Information Options in Redirect Messages,
draft-templin-6man-rio-redirect , Fred Templin, 10 min.  

IPv6 in-band signaling for the support of transport with QoS,
draft-han-6man-in-band-signaling-for-transport-qos , Lin Han, 10 min. 

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

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

- Reviewed agenda

Document Status Review (slide)
- Reviewed parked document, drafts in IESG
- Quick review of active drafts

Documents of Interest (slide)
- Review documents in opsec, v6ops, and segment routing
- Comment from Erik Kline - incoming document from ipwave (incoming
  potential documents and discussion for 6man) 
- Ron Bianca volunteered to look at Spring documents
- Suresh 

IPv6 Core standards next steps? (slide)
- quick review of slide


NAT64 Experiment, Jen Linkova
-----------------------------

IPv6 Only Experiment (Presentation) 
- Jen Linkova
- Discussion of desire to use NAT64 SSID, IPv6 based SSID
- Report issues to "tickets@" mailing list


IPv6 Node Requirements, draft-ietf-6man-rfc6434-bis, Tim Chown, 30 min. 
-----------------------------------------------------------------------

- Review of slides
- Discussion of comments and feedback 
- includes list of changes
- RFC4191 comment (from Erik)
      - Comment Brian Carpenter on the comment re: MUST vs. SHOULD
- Text on IPv6 EH processing (slide)
      - asking group for comments or texts
      - Comment Fernando Gont
- DHCPv6-PD
- Unknown ULP issue
      - quick review of slide data
      - discuss proposed text from next slide (10)
      - Comment Erik Nordmark
      - Comment Brian Carpenter - 
      - Comment Bernie Volz - what happens if someone asked for EH response? 
- response text in RFC8200
      - Cite RFC1122
      - request from Fred Baker
      - Comment Fred Templin - text related to backwards compatibility
        would appropriate   
      - Unless they get 
- Update DHCP vs RA options text
      - can expanded on it, but have left is as is for now (section 8.4)
      - can avoid topic (TW's opinion)
      - Comment Suresh Krishnan - agree to keep it minimal (would not be
        successful in a short time) 
      - Comment Lorenzo Colitti - regarding stateful vs stateless -
        should do what the network asks us to do
      - Comment Suresh Krishnan - the "network" does not tell you want to
        do 
      - LC - trying to recall text, discuss what the draft says related
        on the "SHOULD" statement related to what the Network sets 
      - SK - failure of working group to specify
      - LC - suggests if the host is privacy sensitive, we should drop
        the SHOULD 
      - ongoing discussion  on matter

- IPv6 only host (NAT64) 
      - comment (from?) - 
      - comment Alexandre Petrescu - re: IPv6 only hosts if there is IPv4
        present (vs. translation)  
	      - comment Ole, if you don’t IPv4 have address, its IPv6
                only 
	      - comment Lee Howard - we have terminology problem,
                recommended wording 
	      - continued comments on nuances of working (re: need for
                IPv4 stack, etc) 
	      - comment Suresh - DNS64 is a man in the middle (DNSSEC is
                to stop)
              - question is do we want to synthesize the record
	      - comment Alain Durand - comment about failure rates
                related to use of NAT64 
-                - comment Alexandre Petrescu - other comments related to
                   IPv6-only challenges and issues 
	      - comment / Bob H - should we put in only requires of IPv6
                only host 
	      - comment Lorenzo - regarding points 1,2?  clarify needs if
                we are doing DNSSEC validation with NAT64 (suggested
                wording) 
		      - recommends that “if you do DNSSEC”, then note
                        that the first two points on slide are suggested
                        to be done 
	      - comment Chongfeng Xie - discussion of LTE devices, and
                they have different requirements  
		      - response from Suresh - notes that the draft
                        relates to general requirements, and one can have
                        more restrictive requirement for certain use
                        cases 
	      - comment David Schinazi- this should be about IPv6
                notes/hosts.  Notes that comm with IP4 literals should
                not be about that - suggests DNSSEC text should not be in
                the document / not requirement for iPv6 host 
	      - comment Mark Andrews - comments that this should discuss
                what you need to use IPv4 as a service with iPv6 host  
	      - comment Barbara Stark - if there is a MUST, ever device
                in every use case should need this (suggests that is not
                sure related to NAT64/DNSSEC 
	      - comment Mikael Abrahamsson are all points on this list a
                “must”? 

- Document status?
      - should this be info or BCP?
      - no comments

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

IPv6 ND PIO Flags IANA Considerations, draft-troan-6man-ndpioiana , Ole
Troan, 10 min. 
-----------------------------------------------------------------------

- Discuss slides, came out of issue for RFC4861 PIO
- Problem that 6275 took another bit of reserved field
- this creates new registry , updates 6275, but not 4861
- adoption ?
      - comment: Lorenzo C, comment on approach. 
      - comment  Suresh K there is stuff to be done here, we have general
        issues with updates and flags in the IETF 
      - comment form Old, larger issue on how to manage reserved fields
        and update them 
      - comment from Suresh - gave example of reserved field with flag.
        what happens to implementations that already exist 
      - Ole/Suresh - don’t see issue
      - comment - Erik Kline - support
      - comment -  Mikael Abrahamsson / response from Suresh on policy on
        experimental, reserving of bits etc 
      - comment Alexandre Petrescu
      - comment Erik Nordmark - do experiment, then get the / reserve the
        bits 

- support for WG doc?
      - some hums for support, / no response for not support
      - Chairs will confirm to adopt on the mailing list.


Recommendations on the Filtering of IPv6 Packets Containing IPv6
Extension Headers, draft-ietf-opsec-ipv6-eh-filtering , Ron Bonica,
15 min.
--------------------------------------------------------------------

Presentation not given.


Recommendation on Temporary IPv6 Interface Identifiers,
draft-gont-6man-non-stable-iids , Fernando Gont, 15 min. 
--------------------------------------------------------

- discuss intro with draft
- tries to address issue with RFC4941 / related to use of Temp addresses  
- discuss goals of document / start with security requirements for the TA 
- discuss requirements for non-stable IIDs / there are a number of issues
  here 
- comment: Alexandre Petrescu when changing the IID, one needs to be
  careful (when moving from one network to another)  
	- speaker - you can randomize the MAC address
- comment : Lorenzo Colitti is the algorithm currently specific day 4941
  allowed or disallowed?  / concerned we should not throw out
	- speaker if we keep 4941, we need to patch 
	- Chair - we can move that to BIS document for 4941
	- ongoing discussion about how BIS could be used to
          update. change items from 4941 
	- comment Suresh K - WG should maintain it’s specs (which
          indulges 4941) 
 	     - SK notes, the WG should decide if we create a BIS or
  	       this new draft.  either way it can be the same result  
	     - no matter what we do (based on SK) ,we should
               obsolete it (4941) 
	- comment Lorenzo Colitti - we would end up in better place to
          rev 4941, and fix the bugs - noted examples 
	- comment Lorenzo Colitti - update language on IID / EUI64
          addresses  
	- comment Eric Vyncke - comment related to state which is
          required / confirmed by Erik Kline 
	- comment Erik Kline - 4941 BIS should update the deployment
          section 


IPv6 Address Usage Recommendations,
draft-gont-6man-address-usage-recommendations , Fernando Gont, 15 min.  
----------------------------------------------------------------------

- Discuss draft / intro
- Provided summary of document - problems when using multiple addresses
  with APIs 
- discuss problems with both incoming and outgoing connections   
      - example, use of TA for outgoing, can then be used for incoming
        connection (found in wild) 
- Q - how many people read document ? only 2 people
- Chair, ask speaker was there information exchange with Dave Thaler ?
  suggests this belongs in transport  
- Comment George Michaelson  Suggests we should be able to set
  conditional flags, (general model), suggests work should not be here 
- Comment Suresh K - kinda agrees with George (even if Socket API was
  done in 6man)

  Chairs take the action to discuss with Transport/Apps regarding where
  this document belongs.


Route Information Options in Redirect Messages,
draft-templin-6man-rio-redirect , Fred Templin, 10 min.  
-------------------------------------------------------

- Motivation is to allow neighbors to share routing information with many
  nodes , and where tradition routing protocols are impractical.
- RIOs were originally included in 4191 which has Type A, B and C hosts
- this introduces new type D host (would update 4191)
- comment Ole T, whats the purpose of the S flag? can we just do redirect?
      - speaker response - discussed the ability to have a trust / confirmation 
- Comment Brian Carpenter - comment on motivation for large networks -
  apart of WiFi where is the use?
      - speaker example airplanes world wide (10K nodes)
      - BC - how is the any better then just routing?
- Comment Erik Nordmark - concerned about security implications , re:
      - traditional models where you trust only your main router/gateway
      - , anyone can inject any route for anything?  
- Comment Lorenzo Colitti - have we fixed issue where router can’t depreciate the prefix?
      - continued discussion on how state is managed, how the router
        participates with pulling back prefix 
      - LC says we may need applicability statement here (to refine how
        this will be used) 
- Comment  Erik Nordmark - is there a lease time on this updates? answer Y
- Comment Erik Kline - Q on prefix invalidation and confirmation from
  speaker on process
- Comment Chair (Bob) - concerns that WiFi does not support type of
  communication (direct peer to peer) that is listed in the document  
- Comment Chair (Bob) - also feels that type D host seems like a router
- Comment Lorenzo Colitti - suggests no real benefit 
- Chairs as people to read and comment on list


IPv6 in-band signaling for the support of transport with QoS,
draft-han-6man-in-band-signaling-for-transport-qos , Lin Han, 10 min. 
---------------------------------------------------------------------

- speaking provides quick overview draft, will also be presented in
- transport area meeting.
- motivation reviewed with audience
- speaker reviews slides on transport control sub-layer 
- speaker reviews slide for IP in-band signaling and QoS for transport 
- review solutions slide
- review in- band signaling slide / with diagram 
- Comment Erik Vyncke, recommended some text removes and comment on EH.


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