Minutes IETF101: 6man
minutes-101-6man-00

6MAN Working Group - London IETF Meeting
Monday, 19 March 2018, 13:30-15:30, 1W Viscount

Chairs: Bob Hinden, Ole Troan

Minute taker: Jordi Palet, Eric Vyncke
Jabber Scribe: Mikael Abrahamsson

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

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

Agenda

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

Working Group Drafts

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

IPv6 Segment Routing Header (SRH) draft-ietf-6man-segment-routing-header
, Darren Dukes, 20 min.

Multi-Vendor Interoperability Testing Results Update, Carsten
Rossenhövel, 5 min.

Active Individual Drafts

ICMPv6 errors for discarding packets due to processing limits,
draft-herbert-6man-icmp-limits , Tom Herbert, 20 min.

IPv6 Router Advertisement IPv4 Unavailable Flag, draft-hinden-ipv4flag ,
Bob Hinden, 20 min.

New Individual Drafts

IPv6 Performance Measurement with Alternate Marking Method,
draft-fioccola-v6ops-ipv6-alt-mark , Giuseppe Fioccola, 10 min.

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

Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
draft-gont-6man-rfc4941bis , Fernando Gont, 5 min.

Unified Identifier in IPv6 Segment Routing Networks,
draft-mirsky-6man-unified-id-sr , Greg Mirsky, 5 min.

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

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

Since last meeting RFC8319 has been published

Several documents of interest in other WGs

Eric Vyncke -> there is one more document in the Internet Area about IPv6
provisioning domains (PvD)

Suresh Krishnan -> another document in IPWAVE
draft-ietf-ipwave-ipv6-over-80211ocb


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

  Tim Chown presenting. Is a 6-7 years old document that need a
  refresh. 1 slide summary of changes since IETF100.

  If everybody is happy with the actual status, we can ask if we can
  advance it.

  Ole Trøan. Any observations considering this morning presentation at
  v6ops about router requirements. One difference being the router MUST
  support DHCPv6 while node SHOULD support DHCPv6 and Tim Chown is happy
  with this difference.  Tim Winters confirms the reference was removed
  so only informally mention.  [Note: reference was still in current
  version.] 

  Barbara Stark confirms she likes the updates done.

  ACTION: Chairs will advance the document to IESG.


IPv6 Segment Routing Header (SRH) draft-ietf-6man-segment-routing-header
, Darren Dukes, 20 min.
------------------------------------------------------------------------

  Darren Dukes presenting.

  Ron Bonica: this draft has been stable for a few years. There is
  another draft (about network programming) which is still moving and
  includes some shocking issues for this WG such as two RH in one
  packet. Either merge both drafts or last call them together. Ron and
  Darren disagree on the fact that SID could play a similar role to
  L3VPN.

  Suresh Krishnan: Do you have a plan to update the other document (on
  header insertion)? I don't want to hold this for ever, so I really want
  that to progress.

  Zafar Ali: drafts will be reviewed anyway in other WG

  Suresh Krishnan: That's what I've said.

  Ron Bonica: Question about issues with implementations?

  Presenter: if you're implementing now, let's have that discussion.

  Zhenbin Li from Huawei: we are also implementing SRv6.

  Suresh Krishnan: You can add a section about specific implementation
  details.

  Bob Hinden: There are no normative references in the document, they are
  all informational, that should be fixed and Darren agrees to fix this
  issue quickly.

  Darren what are the next steps. Bob is comfortable with starting the
  WGLC.

  ACTION:  Chairs will start working group last call.
  

Multi-Vendor Interoperability Testing Results Update, Carsten
Rossenhövel, 5 min.
------------------------------------------------------------------------

  Nobody available to present on this, so skipped.


ICMPv6 errors for discarding packets due to processing limits,
draft-herbert-6man-icmp-limits , Tom Herbert, 20 min.
------------------------------------------------------------------------

  Tom Herbert presenting about having a new ICMP error code to indicate
  that the middle box cannot handle the EH chain (too long, too many
  headers, ...).

  Darren Dukes: what to do when using ASIC because I cannot move the
  pointer to the next extension header which is beyond the ASIC
  visibility. I will send an email about this.

  Tom Herbert: We should point to something after that. The point is taken.

  Suresh Krishnan: Push that to the slow path.

  Bob Hinden: Skeptical that hosts to make any use of this. You've not
  convinced me about that.

  Tom Herbert: Extension headers aren't reliable, anything we do improves
  the situation. Feedback is part of that, instead of alternatives such
  as probing. I'm looking for flexibility using extension headers.

  Ole Trøan: What granularity do we want? What are the hosts doing with
  those ICMP codes? Is parameter error sufficient? The ecosystem to use
  this is quite big.

  Mikael Abrahamsson: Is there a way to tell the hosts to filter a
  specific extension header?

  Suresh Krishnan: Is that a parameter problem?

  Lorenzo Coliti: if you write code yes, but nobody wrote it yet.

  Mikael Abrahamsson: I'm not talking about this. If I've a firewall that
  want to filter something, do I've a way to signal that I'm going to
  filter that?

  Michael Ackermann: We don't have network management for that.

  Ron Bonica: could be useful to detect issue in tunnels

  Chairs do a hum to get a sense for adopting this document as a WG
  item. Excellent, seems room in favor of vote for adoption and will
  confirm in mailing list.

  ACTION: Chairs will confirm adoption on the mailing list.
  

IPv6 Router Advertisement IPv4 Unavailable Flag, draft-hinden-ipv4flag,
Bob Hinden, 20 min.
------------------------------------------------------------------------

  Bob Hinden presenting. The I-D could prevent a dual-stack host to use IPv4
  even in the absence of IPv4 (could limit the amount of broadcast and
  the waste of battery, ...). Just a 4 flag in RA, default value 0
  means that IPv4 is present.

  Mikael Abrahamsson: You said "flag set administratively and not
  automagically"? If the upstream is PPPoE only (so the CPE does not know
  before PPPoE whether IPv4 is present)?

  Juliusz Chroboczek: Why is a flag and not an option? I see 3 values.

  Bob Hinden: What do you expect the host do to differently in that case?

  Juliusz Chroboczek: In the future when networks don't have IPv4
  anymore, should we really still use a 'useless' flag?

  Bob Hinden: Is good to remember history ... We could probably reclaims
  the flag. It is a very small problem, is not so bad.

  Lorenzo Coliti: We need to stop to disagree in the problem to find the
  right solution. We don't have a clear definition of what it means.

  Suresh Krishnan: I don't want to have sunset4 again. Let't other people
  talk ...

  Peter Stevens: what if there is IPv4 but only local in the LAN w/o IPv4
  router?

  Lee Howard: Flat set: I'm not the default gateway for IPv4. There is a
  useful clarification to be made in the document.

  Jen Linkova: We need to state if it means public IPv4 or also
  link-local.

  Bob Hinden: The goal is no IPv4 addresses at all.

  Barbara Stark: I think is useful and doesn't harm.

  David Schinazi: what kind of network would use this? Home network?
  Enterprise? IETF Network? I want to be able to still use the old
  IPv4-only printer over IPv4 link-local, use Bonjour ...

  Bob Hinden: Then you don't set the bit.

  Veronika McKillop: about to deploy IPv6-only network within Microsoft
  IT, so this I-D is a good idea and she wants this.

  Jen Linkova: I see the case for enterprise ...

  Suresh Krishnan: I personally support his work, but we need to see how
  to progress. Sunset4 is ideal but not many people left there ... Happy
  to keep doing it here.

  Friso Feenstra: what is someone is sending this RA with this flag on a
  fully functioning IPv4 network.

  Suresh Krishnan: Is a different draft, note that this work is only
  specifying: "I'm not an IPv4 router".

  Suresh Krishnan: why not removing all behaviour from the I-D? Up to the
  host to decide what to do

  Fernando Gont remotely:

  Jen Linkova: Is a good thing that you can completely turn off IPv4, is
  a security issue.

  The chair did a hum, there was majority for adoption, with a
  significant minority against. To be confirmed on the mailing list.
  
  ACTION: Chair will confim adoption on the mailing list.


IPv6 Performance Measurement with Alternate Marking Method,
draft-fioccola-v6ops-ipv6-alt-mark , Giuseppe Fioccola, 10 min.
------------------------------------------------------------------------

  IPv6 Performance Measurement with Alternate Marking Method,
  draft-fioccola-v6ops-ipv6-alt-mark , Giuseppe Fioccola Giuseppe
  Fioccola presenting: using 1 or 2 bits in every packet (same marking
  for one period of time) within one managed network and checking at the
  end of the path. Of course, 2 bits need to be found IPv6 packets (dest
  address, in HbH or Destination Options, flow label, ...).

  Ole Trøan: Clarification question. Are you talking only about
  traversing packets in your network or also originated in your
  network. Do you talk also about header injection?

  Giuseppe Fioccola: Is an open question, but in principle both cases. We
  are experimenting only, we know there are some issues, we want to get
  some inputs.

  Lorenzo Coliti: I wonder if we should use the flow label that nobody is
  using anyway.

  Suresh Krishnan: The main issue is that somebody is using those bits
  for hashing in load balancing.

  Tim Chown: We have updated the flow label behavior and a node cannot
  change the flow label if is not 0... but some systems may set it.

  Suresh Krishnan: The problem is that the flow label need to be
  delivered as initially set.

  Lorenzo Coliti: Use TCP/UDP, so use the checksum.

  Giuseppe Fioccola: but is not IP and may be the SLA is on IP.


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

  Ole Trøan: No comments from the room at the time being, so continue
  with the next document, as they are related.


Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
draft-gont-6man-rfc4941bis , Fernando Gont, 5 min.
------------------------------------------------------------------------

  Dave ?: Needs to specify "unprobably"

  Fernando Gont: I don't expect you remember the previous values.

  Tim Chown: You need to define the property of those addresses. Not
  predictable?

  Lorenzo Coliti: Base it in the algorithm from the previous RFC is a
  bad idea because it is predictable once the secret is known. It should
  be randomized so it is useful for privacy.

  Bob Hinden: Looking at the diff is very messy to find the changes.  It
  would have been better if a -00 draft has been a base line from the
  original RFC.  Then -01 can have the changes.  

  Suresh Krishnan: The issue are the RFC editor edits, this draft was
  based on Suresh's XML, not the final output from the RFC Editor.  The
  RFC Editor and AUTH48 changes were lost.  

  Lorenzo Coliti: Let's delete the text for algorithms and just say it
  should be random.

  [After the session, the chairs request that the author start with a new
  filename using the RFC Editor XML to create a new baseline.]


Unified Identifier in IPv6 Segment Routing Networks,
draft-mirsky-6man-unified-id-sr , Greg Mirsky, 5 min.
------------------------------------------------------------------------

  Ole Trøan: We have time for one question. Have you presented in SPRING?

  Greg Mirsky: They have a too tight agenda. Agree they should be aware
  of it.

  Darren Dukes: I do not see this I-D being applicable to any SPRING
  use-case.


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