Minutes IETF99: 6man
minutes-99-6man-00

6MAN Working Group - Prague IETF Meeting
Monday, 17 July 2017, 9:30-12:00, Grand Hilton Ballroom
Chairs: Bob Hinden, Ole Troan

Minute taker: Barbara Stark
Jabber Scribe: Mikael Abrahamsson

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

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

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

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


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

IPv6 Specifications to Internet Standard Status, Ole Troan, 5 min.

Update on rfc4291bis, draft-ietf-6man-rfc4291bis, Bob Hinden, 20 min.

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


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

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

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


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

Tweaking Default Address Selection,
draft-linkova-6man-default-addr-selection-update, Jen Linkova, 10 min.

Proposals to discover Provisioning Domains,
draft-bruneau-intarea-provisioning-domains, Pierre Pfister, 10 min.

The AERO Address, draft-templin-6man-aeroaddr, Fred Templin, 10 min.

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


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

Note well was noted.

Reviewed status of w.g. documents and Charter milestones.


IPv6 Specifications to Internet Standard Status, Ole Troan
--------------------------------------------------------------

Ole walked through the chair slides:
https://www.ietf.org/proceedings/99/slides/
slides-99-6man-introduction-agenda-bashing-document-status-01.pdf

On document status (1 of 2) page:

Suresh Krishnan: I sent 4291bis back because I'd really like the WG to
solve the problems with 4291bis. I don't think they've been solved.

Lee Howard: Noted error on slide where RFC numbers were
swapped. Requested this slide (slide 9) should be the last thing
discussed during meeting today.

Ole: Yes

Erik Kline: The documents do not have to all be done together.



Update on rfc4291bis, draft-ietf-6man-rfc4291bis , Bob Hinden
--------------------------------------------------------------

Presented slides:
https://www.ietf.org/proceedings/99/slides/
slides-99-6man-rfc4291bis-to-internet-standard-00.pdf

Paused on slide 4, asking for comments

Randy Bush: Prefixes do not need to be restricted to 64 bits. SLAAC is
not limited to 64 bits.

Lee Howard: You are actively describing how the Internet is running
now. Is the crux of the argument over the word "manually"?

Lorenzo Colitti: This is close to what we've always had in standards. The
value of the 64 bit number is to reserve for future use the definition of
how to better use them.

Job Snijders: I do see value in /64 but would hate for it to happen that
implementations can't support other lengths. Perhaps remove /64 reference
from the document. Everything that needs /64 can specify it in their own
doc.

Bob: There is text that routing should work with any prefix size. The
fact that hardware should work with prefix of any length is handled in
unicast section.

Job: I would like to see this text removed.

Jordi Palet Martinez: I support restricting to /64.

Jen Linkova:

Fernando Gont: Don't want code to break.

James Woodyatt: Would like for there to be a compromise. Removing text
may be a good compromise. In favor of taking it out.

Bob: I don't think it does harm.

James: It hasn't helped.

Mikael: We should figure out a better word than "manual".

Lorenzo: I really don't like that text.

Toerless Eckert: Someone might read this and not read all other docs and
that might not be good.

Randy Bush: Classless IPv6 is a standards track doc.

Lorenzo: Would we want Classless IPv6 without updating RFC 4291?

Suresh: The point no-one talked about is what IID means, for example, for
DHCPv6. I think we're having a lot of good discussions. But we need to
make more progress to have everyone on same page when talking about IID.

Christian Huitema: What I would like to see is maybe a problem statement?
How do we do that?

Bob: Will you write that?

Christian: If I can get help?

Bob: I will help you. Thank you.

Erik: A problem statement might help.

Randy: I have sympathy with Christian's expression of the problem. We
need to avoid promoting NAT. We're trying to embed in the address
architecture a way to tell operators how they should run their
networks. We need to get operators to do what we want by up-selling on
positive aspects of doing what we recommend. It's tragic tat it's getting
more difficult to explain to people how to create an IPv6 network.

Lorenzo: I think you're right, Bob. No matter what we do there will be an
argument. But if we don't have a boundary, we will end up with /128 as
the boundary.

Lee Howard:

Tal Mizrahi: Implementers need to know what to implement. The way I read
this text is: the IID is not necessarily 64 bits long, but the
implementation should be optimized for 64-bit IIDs.

John Brzozowski: You need to be careful. Making the IID shorter could
have ramifications.  ? Add text to justify the decision

Bob: We don't have consensus. Maybe if we write a doc about problem
statement and get consensus on that we could eventually get consensus on
this.

Randy: I thought we did. <Randy mentioned Classless IPv6 draft he thought
did this.>

Lorenzo: The question I have never seen answered is "What can we do with
longer IPv6 prefixes that we can't do with /64 prefixes?"

Barbara Stark: Where is the evidence that operators will use longer
prefixes if we allow it?

Lorenzo: They will.

Job: I'm optimistic that companies will assign ample space if they are
encouraged to do so.

Christian: We need a problem statement.

Jen: We do see evidence of operators doing things that are not
recommended.

Ole: I'm not quite sure what the path forward is going to be. Let's see
if we can do more work around problem statements and figure out what
problem we want to solve.

Suresh: Maybe an interim would be useful. Maybe something more focused
would help.  Lorenzo: I agree. And we do have work ahead of us.


IPv6 Node Requirements, draft-ietf-6man-rfc6434-bis , Tim Winters
-----------------------------------------------------------------

Presented slides:
https://www.ietf.org/proceedings/99/slides/
slides-99-6man-rfc6434-bis-ipv6-node-requirements-update-01.pdf

Slide 10 (re jumbograms)

Tim Chown: You're running off older slides. Brian's comment was there was
no harm keeping as is. We changed to say we're thinking of keeping it.

Mikael: I would like to keep it. Could we use other words?

Joel Jaeggli: Large packets cause increased latency of other packets. 

James: I would like to see some consensus as to what it should say. What
references to use. Like 4291. I would rather it say "Type A" than what it
says now.

Erik Kline: I would also like to see some sort of 4291 references.

Tim Winters: We'll take a look at that.

Slide 11 (3GPP)

Suresh: Get with Med and talk about it.

Lorenzo: Why are we publishing a new document that will trump other docs?

Tim: We're saying read this other doc, if this is what you're doing.

Suresh: That's just a snapshot.

Tim W: 

Tim C: 

Lorenzo: Can't we just say if you support a link layer with broadcast,
this is what you do.

Tim W: Something we'll have to think about.

Slide 13

Tim C: <Clarified slide>

Lorenzo: There's a conflict between what we recommend in various
places. We need to make up our minds.

John Brzozowski: I think the MAY is good.

Tim W: We can talk about the MAY.

Nathalie Trenaman: 

Fernando: There is a BCP that says don't do DHCPv6?

Lorenzo: It says don't do DHCPv6 only.

Barbara: The BCP Lorenzo mentions applies to a specific use case and RFC
6434 is for all nodes.

Suresh: If you get PIO with no A, then do DHCPv6.  Now with AD hat on:
Getting rid of DHCPv6 is not an option.
   
Randy: Doesn't care if they like vanilla, chocolate, or strawberry. Wants
to move them from unhealthy corn syrup to better ice cream.

Ole: With that we end.

Tim W.: Will update. Have some topics to discuss at next IETF.



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

Presented slides: https://www.ietf.org/proceedings/99/slides/
slides-99-6man-route-information-options-in-neighbor-discovery-messages-00.pdf

Ole (at mic, not as chair): Why isn't it sufficient that it sends RIO
option in RA (in context of slide 6)?

Fred: <explained>

Eric Vyncke: It sends to destination address?

Fred: No.

Jen: How does it indicate it no longer has the prefix?

Fred: Send NA without that route. And it sends Network Unreachable.

Mikael: 

Fred: If it's a /112, then it sends a /112. Larger prefixes are ok.

Bob: Clarifying question. This is confusing. It's a router, right?

James: It might not be a router in 6man terms. No. Wait. It would have to
be a router.

Fred: It could just be a bluetooth device.

Lorenzo: Expressed concerns about info being updated.

Lorenzo and Fred discussed details.

Jen: Can it send RA?

Fred: RA response to RS is normally multicast but unicast is allowed.

-- out of time --


IPv6 Address Usage Recommendations
draft-gont-6man-address-usage-recommendations , Frenando Gont
---------------------------------------------------------------------

Presented slides:
https://www.ietf.org/proceedings/99/slides/
slides-99-6man-address-usage-recommendations-01.pdf

At end of slides:

Ole: Has anyone solved this?  Fernando: Not that I know of.

Erik Kline: Something that should be worked on.

Eric Vyncke: 

Thomas Pauly:

Philipp Tiesel:

Ole: Unsure if this is for transport and above problem space. Need to
talk to our AD and transport people.

Dave Thaler: People wanting to do APIs and specific languages done by
other SDOs should talk to me.

Mikael: Useful for people to think about this problem space. No opinion
on where to do it. We need a replacement to the open socket API that
isn't proprietary.

Dave: This org needs to abstract the API. The model is in scope for us,
but not the actual API.

Bob: What Dave recommends is a good path forward.


Tweaking Default Address Selection,
draft-linkova-6man-default-addr-selection-update , Jen Linkova
--------------------------------------------------------------------

Presented slides:
https://www.ietf.org/proceedings/99/slides/
slides-99-6man-making-default-address-selection-more-fool-proof-00.pdf

Lorenzo: I think our Linux workstations are already doing this. But if
they're already doing this and it's not helping, then it may not be the
solution. This feels like a crutch.

Jen: Some vendors have been asked to send RA every time.

Lorenzo: Well maybe this will work.

Suresh and Jen discussed having multiple routers.

Tim W: My preference would be to just fix it with the preferred lifetime
and base the decision on that.

Jen: OK.

Dave: Multiple comments. <comment on using longest prefix> <discussed
avoiding renumbering of rules>.

-- out of time --


Proposals to discover Provisioning Domains,
draft-bruneau-intarea-provisioning-domains , Pierre Pfister
--------------------------------------------------------------------

Presented slides:
https://www.ietf.org/proceedings/99/slides/
slides-99-6man-discovering-provisioning-domain-names-and-data-00.pdf

Pierre would like feedback.

Jen: Do you explain how to do... ?

Pierre: The goal is to get the right source address.

Dave: I understand this and think it works for regular hosts but not
constrained hosts.

Pierre agrees.


The AERO Address, draft-templin-6man-aeroaddr , Fred Templin
------------------------------------------------------------

Presented slides:
https://www.ietf.org/proceedings/99/slides/
slides-99-6man-the-aero-address-00.pdf

There were no comments or questions at this time.


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

Ole: Thank you. 

Went back to slide 9 of chair slides.


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