Skip to main content

Minutes for 6MAN at IETF-93
minutes-93-6man-2

Meeting Minutes IPv6 Maintenance (6man) WG
Date and time 2015-07-20 11:00
Title Minutes for 6MAN at IETF-93
State Active
Other versions plain text
Last updated 2015-07-29

minutes-93-6man-2
6MAN Working Group - Prague IETF Meeting

Monday, 1300-1500, 20 July 2015, Congress Hall III          
Chairs: Bob Hinden, Ole Troan          

Minute taker: Lee Howard, Suresh Krishnan          
Jabber Scribe: Andrew Yourtchenko, Loganaden Velvindron          
          
Jabber Room: 6man@jabber.ietf.org          
Meetecho: http://www.meetecho.com/ietf93/6man                    

Slides can be found at: https://www.ietf.org/proceedings/93/6man.html

The full recording (synchronized video, audio, slides and jabber room) of
the  6MAN WG session at IETF 93 is available at
https://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#6MAN 

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

Working Group Drafts

     None.

Active Individual Drafts

     Republishing the IPV6-MIBs as obsolete
     draft-fenner-ipv6-mibs-obsolete, Bill Fenner, 10 min. 

     Source Address Dependent Routing for IPv6 hosts analysis, Brian
     Carpenter, 20 min. 

     IPv6 Hop-by-Hop Header Handling
     draft-baker-6man-hbh-header-handling, Fred Baker, 15 min. 

     IPv6 Segment Routing Header (SRH)
     draft-previdi-6man-segment-routing-header, Stefano Previdi, 10 min. 

     Implications of Randomized Link Layers Addresses for IPv6 Address
     Assignment draft-huitema-6man-random-addresses, Christian Huitema,
     10 min. 

     IPv6 specifications to Internet Standard, Chairs, 20 min.

New Individual Drafts

     RA power measurements, Lorenzo Collitti, 5 min.

     Guidelines for New Router Advertisement Options
     draft-sarikaya-6man-ra-guidelines, Dan Ludtke / Behcet Sarikaya, 5
     min. 

     CGA SEC Option for Secure Neighbor Discovery Protocol
     draft-jiang-6man-cga-sec-option, Sheng Jiang, 5 min. 

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

     DNS Name Autoconfiguration for Internet of Things Devices
     draft-jeong-homenet-device-name-autoconf, Jaehoon Paul Jeong, 5
     min. 

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

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

Meeting started promptly at 1300.

Chairs requested comments on DAD improvements, on the mailing list.

Remote question from Ted Lemon: Would chairs entertain a question about
DHCPv6-Shield and IPv6 Extension Headers?  The chairs didn't understand the
context, and asked Ted to raise the issue on the mailing list.


Republishing the IPV6-MIBs as obsolete
draft-fenner-ipv6-mibs-obsolete, Bill Fenner, 10 min. 
-----------------------------------------------------------------

Old MIBs are obsolete, but the descriptions don’t actually say that. 
So this draft changes that.

Two thumbs up from the AD.

Adopt as a WG doc? Loud hum in favor, no opposition.  Chairs will confirm
on the mailing list.

Republish as a 6man doc.

Dave Thaler: Are there any open issues, or can it go to WGLC?

Bill:  I have no open issues, but please review.

Dave Thaler: I will review.


Source Address Dependent Routing for IPv6 hosts analysis, Brian
Carpenter, 20 min.  
-----------------------------------------------------------------

Should 6man do something about source-address dependent routing?

Recommend reading draft-baker-rtgwg-src-dst-routing-use-cases and
draft-sarikaya-6man-sadr-overview 

Problem: a host with more than one GUA wants to send packets to a host
with more than one GUA, and at least one upstream network implements
BCP38.

Lorenzo: if it’s one routing cloud, how can this happen?

Fred: You wind up getting to a different egress router, evenwhen your
first hop is the same physical interface

Lorenzo: How can they be separate if it’s the same interface?

Fred: There would be one overlapping device.

Bob: e.g., cable and DSL, where both exist but don’t route between each
other.
 
Sub-optimal routing or performance is not a failure mode.

Dave Thaler: selection of address pair is done sometimes by app and
sometimes by stack

Fred Baker: what does “sub-optimal” mean in this context?

Mikhail Abramsson: What do you mean you don’t care?

Brian: It doesn’t need fixing.

Mikhal: I disagree. In some use cases, an extra hop is a problem.

Pfister: It is a failure. I have two routers on my WiFi and we don’t want
each packer to be retransmitted twice.

Phil: Routers can just figure it out, we still have redirects. If we have
two routers than never talk, that’s a problem.

Fred: I thought routing was off the table.  In Use Cases, one question
was whether all routers in the system understand what was being
discussed. But saying “I’m going to select the right number of hops” you
can redirect to the wrong egress.  Therefore, getting to the right egress
is a functional requirement.

[missed name]: Let’s identify blockers now, and do optimization later.
Erik Kline: Would you consider it a failure if you were only supposed to
have one failure on the link, but somebody showed up with another router
and started sending RAs?

Brian: If there’s an ingress filter, it would be a failure.

Pfister: Reply to David. At least you agree that we have a fix to a
problem, and later we have a fix to the fix.

Julius Chrobocek: Aren’t you going to have route flapping,with each
router sending redirect to the other?

Description of scenarios.

Philip Homberg: So we're tying address to routing, which wouldn't occur
if you tied address to DHCP?

Brian: Right, you need to process RAs, whether you're doing SLAAC or not.

Philip: RAs don't say anything about address.

Brian: Except PIO.

Fred: Recommendation that all routers support SADR; don't send to Routing
Area, send to Ops Area.  Routing Area doesn't tell you how to route, it
owns the protocols.

Mikail Abramsson: It's not just that you select source address and get
routing; we need to tie them together. This doesn't do that.

Ole: Yes, requiring stacks to remember which next-hops advertised which
prefix and enabling source-address selection rule 5.5 does this.

Mikhal: But I want to be able to use both source addresses to reach a
single remote host.

Lorenzo: That already works.

Jacques Pfister: Homenet WG. I support fixing observed problems. We're
using SADR in Homenet, but have no drafts defining it. This looks like a
solution. I disagree with this. You're using PIO for routing, redirect, I
don't know how that will work with RIO.

Lorenzo Colitti: Require that RAs are sent. Say you're a lonely /128, do
you send a PIO for yourself?  If everything is off-link, ow?

Brian: If there's only one, no problem. Get address from DHCP, get RA
with PIO from router.

Fernando Gont: Does the fact that a router sends a PIO mean you have to
send packets to that router?  Brian: Not currently defined, but seems
like that's what you have to do to make it work.

Ole: Assumes if you send PIO, you should expect to route.

Brian: 5.5 only applied to those who understand the prefix and route it.

Marcus Steinburg: I applaud work in this space, but not this solution.
Funny: Routing Area doesn't choose for you, except in Homenet they are.

Hunter (?) does any of this imply host installs two default routes, each
with source prefix?  audience: Yes, no, yes.

Brian: Default it a weird thing,

Steven Barth (?): I've been doing something like that on CPE for a while
now. We do on an interface basis. For every PIO and PD, we're making the
router source-specific. Works well, not sure how to do in host stacks,
especially constrained devices.

Bob: Is there interest in the WG in working on this along the lines of
Brian's conclusion?  strong hum

Lorenzo: Does that preclude working on other stuff at the same time.

Mark Townsley: The hum should be for the first slide (should we work on
this problem?),  not the last slide (Brian's conclusions).

Moderate hum to work on this.

Fred volunteers to co-author with somebody.   Brian might help.

Brian: Let's remember what Pierre said, that sub-optimal can be a real
penalty, not just an annoyance.

Lorenzo: Want more discussion of alternatives.

Fred: I think we can do this without getting into a routing protocol.


IPv6 Hop-by-Hop Header Handling
draft-baker-6man-hbh-header-handling, Fred Baker, 15 min. 
-----------------------------------------------------------------

HBH punts to software, which is an attack vector. Either fix it or
deprecate it.  Cisco looking at some OAM questions which could overlap.
Recommend: presence of HBH SHOULD NOT slow forwarding rate. If HBH can be
skipped, it MUST be skipped.

Change in place supported by rfc2460, but what if host is unaware?  Might
be okay. Unless it's in ESP and checksum no longer matches. Thus, header
must be restored to original before final delivery.  This OAM might only
work among consenting networks; interop is a concern.

So, either deprecate all extension headers.

Bob: You mean all HBH?

Fred: No, all EH break this way, but I'll limit discussion to HBH. And I
think that's a bad idea.

Jen Linkova: Don't deprecate. But why say to skip if you don't know what
to do? There's guidance about what to do.

Fred: I thought I did say that.

Jen: If HBH not implemented, then skip.

Fred: I'll work on wording.

Christian Huitema: Look in ippm WG, options to measure traversal times. I
think that work should be synchronized here; similar use case.

Fernando Gont: Agree with processing of HBH. SHOULD/MUST. But other EH
also have problems. Improving this doesn't fix everthing.

Suresh Krishnan: I support this work. Consider MTU if you're going to add
headers on the fly.

Fred: I think I mentioned in security considerations.

Suresh: How does last hop know what headers were added in the middle?

Fred: I think that's in the option, whatever it is.

Suresh: But if it's the whole header?  Also there's no ordering of
options, so same header could be repeated multiple times, which could be
a DOS vector.

Boro Nis?  Good work, maybe four years late.

Erik Kline: HBH with router-layer options like MLD are not in scope?

Fred: Um. It's a packet with an option, I don't know about what's in it.

Ron Bonica: I agree with you, but we need to do some
soul-searching. Agree that HBH isn't useful because implementations
filter or punt. So, fix. But do we have a good use for HBH options that
makes the work worthwhile? IPv4 equivalent is unused. Different in IPv6?
Probably, but we should be explicit about it.

Ole: Too soon to adopt.  Please keep working.

Fred: I have an offer to co-author.


IPv6 Segment Routing Header (SRH)
draft-previdi-6man-segment-routing-header, Stefano Previdi, 10 min.
-----------------------------------------------------------------

Fernando Gont: rfc2460 EH means [missed comment]

Brian Carpenter: no, segment router header means you are controlling
where the packet goes, so you can assume it will leave network at a point
where it will remove the weed you've planted.  But I'm still nervous
about inserting headers; Steve Deering and Bob Hinden never conceived of
this. I'm sure it works in your lab, because it's a lab. Do not adopt as
Standards Track--Experimental at most.

Stefano: Valid concern. Same as when we added headers to a packet in an
MPLS network. What if we defined the domain to make sure it exited the
domain exactly the same? Not sure this concern pushes back the whole
thing.

Erik Vyncke: No problem on the Internet, because you don't do it on the
Internet.  We've been trying it, and getting 5-10% drop rate.

John Brzozowski: I disagree with Brian. We need to continue examining,
but maybe 6man and v6ops aren't the right place. We see this as necessary
evolution.

Lorenzo Colitti: I don't share Brian's concerns. Always true: if the
network touches the packet, the packet is at the mercy of later
routers. I can see how adding headers could open opportunities for
undesirable or even malicious behavior, but maybe we can limit the
opportunities for mischief.

Alex Petrescu: What kind of services will this network offer using
segment routing?

Stefano: See the use cases draft.

Jean-Michel: I sent a message about security, no reply.

Ole: There are questions about security.

Stefano: I would say there are questions.

Bob: We deprecated the earlier document.

Stefano: That's why we wrote the segment-routing-security draft.

Ole: People who read security draft, any issues, knowing who we
deprecatedRH0?

Jean-Michel: The security considerations section, or the
segment-routing-header draft?

Christian: Please make it one document.

Stefano: We separated based on a suggestion already.

Bob: Please combine, and we'll do a call for adoption.

Stefano: If I submit tonight, do we get a call this week?

Bob: Next week.


Implications of Randomized Link Layers Addresses for IPv6 Address
Assignment draft-huitema-6man-random-addresses, Christian Huitema,
10 min. 
-----------------------------------------------------------------

Don't assume MAC address is constant. Use IEEE rules to set U/G bits, to
show it's a random adress.  rfc7217 recommends stable identifiers.

Lorenzo: Are you assuming there are other addresses too, e.g. privacy
addresses?

Fernando: 7217 doesn't require you to use an interface identifier.

Propose to update 7217 Do we adopt this draft, or revise
draft-ietf-6man-default-iids

Philip Homburg: We have language that;s one-size-fits-all: mobile
devices, large platforms, small things. Update this to say, "If you use
randomized MAC addresses, do this; if you're a stable server, stay
constant." But I think we need to work on this.

Michel Combes: Interaction with SAVI.

Erik Vyncke: I understand your goal, but I'd like to keep rfc7217 stable,
because enterprises are easily confused.

Christian: We solve that now by not doing MAC randomization on enterprise
networks. But it's still a risk since a neighbor can do MAC sniffing on
WiFi. The intersection of enterprise and privacy is not well understood
yet.

Bob: Being on the inside is not safe.

Erik: Okay, keep MAC address random, but keep 7217 intact, randomize MAC
but not IP address.

Christian: That in-between case is harder to test.

Lorenzo: I like this work. Broader questions, not just SAVI, but there's
a lot of infrastructure e.g., captive portals, based on stable MAC
address. Even 802.1x on wireless expects it. I think we'll find out that
the important this is that the MAC address remain stable for a particular
period of time, but changes quickly after.

Christian: I've gotten that feedback several times. Doing a presentation
in INTAREA. Not sure IETF is the right place to do a thorough examination
of MAC address randomization.

Alex Petrescu: Yes, MAC randomization is needed for privacy. If we try to
identify what breaks when we do this. Like DHCPv6 (Lorenzo cheers). A ULA
generation tool will fail.

Jen Linkova: People don't want do deploy IPv6 with SLAAC because they
don't have a way to correlate user with IP address. Would this further
inhibit?

Lorenzo: That's the IEEE's fault.

Dave Thaler: All this does it make IPv6 as bad as IPv4.

Ole: Not sure whether to combine with -default-iids, continue discussion
on mailing list.


IPv6 specifications to Internet Standard, Chairs, 20 min.
-----------------------------------------------------------------

We have several documents at Draft Standard (a status now deprecated),
which after two years without interest should drop to Proposed Standard.
Propose to reclassify as Internet Standard any documents requiring no
changes.  Start work on those that require updates.  Then look at
Proposed Standard documents.

Dave Thaler: Is there another requirement that all normative references
be at the same or higher level when advancing to IS?

Ole: Exceptions are allowed, but try to keep it rare.

Has to go through exception approval process.
   option 1: Reclassify to IS unchanged (same RFC#)
   option 2: Revise and re- classify (rfc6410)
   option 3: don't advance

Recommendation for several documents.

RFC2460 IPv6: 9 updates, 2 errata.  Revise, re-classify as IS.

Bob: it's not clear that all of these meet the requirements

Ole: Incorporate the "updated-by" text, but not always clear whether the
updates are all qualified for IS

Brian Carpenter: rfc2460bis should be much shorter, with references to
the updating docs He is not concerned about the down refs

Lee Howard: Including by reference is the better way. He believes that
some of the referenced documents may also need updating

Bob Hinden: The 2 track standards doc does not talk about updates. Only
about errata. He thinks there is no precedent and we need to create
precedent

Fred Baker: Wants the IESG to reclassify the updating documents en masse
to Standard along with 2460bis.

Brian Haberman, AD: I like Fred's idea to move as a cluster. We have this
problem in other places, where groups of docs need to be moved
together. Will discuss with other ADs.

RFC4291: IPv6 Addressing Architecture. If someone wants to take this on,
please volunteer.

Wes George: It's often really hard to follow the chain of documents. If
you're going to touch it, make it a bis that includes the current status.
instead of letting people guessing the right thing to do by combining 15
references and the newly minted Internet Standard

Lee Howard: Strongly agrees with Wes. We should not shy away from hard
work.  We need a document that describes the standard, which is not the
document we have.

Bob H. Wanted to know if creating a new Standard would create any
confusion in the marketplace

Lorenzo: Agreed with Lee and Wes

Ron Bonica: When we look at any of these, we may get frightened as we
find ambiguity as we try to collapse. If that frightens us, we should be
frightened now.

Bob: In the future when we update documents, we need to make sure the
update is explicitly clear. Sounds like we'll do a -bis of at least 2460
and 4291 Address Architecture. I'll take a cut at 2460.


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

Did not have time to do the presentations on the new individual drafts.
Chair encouraged authors to bring to the mailing list.
     
     RA power measurements, Lorenzo Collitti, 5 min.

     Guidelines for New Router Advertisement Options
     draft-sarikaya-6man-ra-guidelines, Dan Ludtke / Behcet Sarikaya, 5
     min. 

     CGA SEC Option for Secure Neighbor Discovery Protocol
     draft-jiang-6man-cga-sec-option, Sheng Jiang, 5 min. 

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

     DNS Name Autoconfiguration for Internet of Things Devices
     draft-jeong-homenet-device-name-autoconf, Jaehoon Paul Jeong, 5
     min. 

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