Skip to main content

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

Meeting Minutes IPv6 Maintenance (6man) WG
Date and time 2015-03-23 14:00
Title Minutes for 6MAN at IETF-92
State (None)
Other versions plain text
Last updated 2015-04-14

minutes-92-6man-1
6MAN Working Group - Dallas IETF Meeting

Monday, 0900-1130, 23 March 2015, International room
Chairs: Bob Hinden, Ole Troan

Minute taker: Erik Kline
Jabber Scribe: Michael Richardson

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

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


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

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

Working Group Drafts

     Validation of IPv6 Neighbor Discovery Options,
     draft-ietf-6man-nd-opt-validation , Ron Bonica, 15 min.

Active Individual Drafts

     A survey of issues related to IPv6 Duplicate Address Detection, Andrew
     Yourtchenko, Erik Nordmark, 15 min., draft-yourtchenko-6man-dad-issues,
     draft-nordmark-6man-dad-approaches

     IPv6 Neighbor Discovery Optional Unicast RS/RA Refresh,
     draft-nordmark-6man-rs-refresh , Erik Nordmark, 15 min.

     Source Address Dependent Routing and Source Address Selection for IPv6
     Hosts, draft-sarikaya-6man-sadr-overview-05 , Behcet Sarikaya, 15 min.

     Source Address Dependent Route Information Option for Router
     Advertisements, draft-pfister-6man-sadr-ra , Pierre Pfister, 15 min.

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

     IPv6 Segment Routing Security Considerations,
     draft-vyncke-6man-segment-routing-security , Eric Vyncke, 10 min.

     Support for multiple provisioning domains in IPv6 Neighbor Discovery
     Protocol, draft-ietf-mif-mpvd-ndp-support , Suresh Krishnan, 10 min.

New Individual Drafts

     Current issues with DNS Configuration Options for SLAAC,
     draft-gont-6man-slaac-dns-config-issues , Fernando Gont, 5 min.

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

     Improving Scalability of Switching Systems in Large Data Centers,
     draft-zhang-6man-scale-large-datacenter , Ming Zhang, 5 min.

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

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

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

- introductory comments from chairs
- note wells well noted
- Michael Richardson volunteered as Jabber scribe
- agenda bashing
  - Francis Dupont:
    - request to push IPv6 RFCs to full standards
    - hinden concurs, in charter, will talk to area director
- review of document status
  - one request for adoption, on today's agenda (sadr-overview)


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

Validation of IPv6 Neighbor Discovery Options,
draft-ietf-6man-nd-opt-validation , Ron Bonica, 15 min.
-------------------------------------------------------

- Ron Bonica presenting
- adopted as wg item since last IETF
- tightening up the document
- on suggestion from Jimmei Tatuya:
  - if you get a message with a link-layer address option that is your
    own address, should drop (subject to configuration to the contrary)
- Jen Linkova, Google
  - re: one's own address, this sounds like DAD packets
  - might break DAD for link-local address?
  - honor the message but not create an ND entry
  - RFC 4861 validation is per message, this document is per option
    - slightly confusing?
- Fernando Gont
  - consider a host with multiple NICs on a the same link
  - need to consider this corner case
  - Bonica: perhaps configuration option could address this case


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

A survey of issues related to IPv6 Duplicate Address Detection, Andrew
Yourtchenko, Erik Nordmark, 15 min., draft-yourtchenko-6man-dad-issues,
draft-nordmark-6man-dad-approaches
-----------------------------------------------------------------------

- Erik Nordmark presenting, channeling Andrew Yourtchenko
- draft has been reorganized
- open issues (robustness and efficiency)
- interaction with delays in forwarding
  - modem acts as a bridge, but upstream link isn't up so ND messages
    aren't actually being forwarded
  - DAD probes lost
  - resilient-rs solves the problem for RS/RA
- unreliable L2 multicast
  - WiFi, for example, multicast is less reliable than unicast
  - IEEE 802.11aa working on improved multicast reliability (but more
    focused on multicast video stream reliability)
- partitioned and re-joined links
  - only DAD at config time
  - IPv4 has ACD (RFC 5227) which does continuous DAD detection
  - RFC 4862 doesn't specify retry/recover on collision behaviour
  - RFC 4941 (privacy) says generate new IID and try again
  - DHCPv6 should DAD and decline if duplicate
  - as long as link-local isn't duplicate don't need to disable the interface
- energy efficiency
  - WiFi multicast consumes more bandwidth (energy?) than unicast
  - host efficiency: better support for sleeping nodes
- wake-up and L2 events
  - RFC 4862 says do DAD when assigning address to interface, nothing
    about link up/down events
  - DNA (6059) says SHOULD NOT DAD on re-attach to previously visited link
  - seems unfortunate
- Suresh Krishnan:
  - our understanding of duplicate situation was different in the past
  - worth revisiting
  - with VMs we might need to revisit duplicate probability calculations
- Christian Heuitema, Microsoft:
  - scalability of multicast is an issue
  - lots of multicast groups (solicited node)
  - problem with DAD is you're looking for extremely rare events
  - means the code that deals with this doesn't get exercised very often
  - you can do testing by collisions, but those are artificial lab conditions
- Brian Carpenter:
  - observation: DAD is ND for yourself
  - so the problems should apply to ND as well
  - (Nordmark: but ND retransmits, and waits for positive ACK, but how long does DAD wait?)
  - Murphy's law proves collisions will happen
- Christian Heuitema:
  - we have to design that these things are difficult
  - a test at time T is assumed to be valid for some period of time thereafter
  - a continuous mechanism might be better
- Lorenzo Colitti:
  - shouldn't work on efficiency because we consider this to be rare (sleepy nodes)
  - discussion of hosts that sleep on a schedule...
    - LC: if you can't receive a packet you don't have an address
    - EN: DHCPv6, sleep proxies
    - LC: yes, can't solve this without an anchor, but this isn't a priority
  - for multicast efficiency, this is just ND, and if links can't support ND
    then everything falls over
  - for robustness: it's designed as best effort to tell you something is wrong
  - why does this need to be made reliable?
- (Pascal):
  - re: IEEE claims, it's not clear what ND expectations are
  - reliance on MLD is mandated but kind of broken
- John Brzozowski:
  - think we do to solve this, there are links with large numbers of nodes
  - have needed lots of work-arounds
  - EN: to what extent do we care about sleeping hosts
- EN: 6man-dad-approaches
  - continuous DAD, inspired by ACD
  - allow sleep with robust DAD using sleep proxy


IPv6 Neighbor Discovery Optional Unicast RS/RA Refresh,
draft-nordmark-6man-rs-refresh , Erik Nordmark, 15 min.
-------------------------------------------------------

- Erik Nordmark presenting
- periodic RAs can be inefficient on some links, fine for others
- maxRtrAdvInterval tinkering maybe not sufficient
- operator can choose between unicast RS refresh or periodic multicast RAs
- require that RS refresh hosts MUST implement resilient-rs
- proposed RS flag: R-flag
  - this host can do unicast rs refresh
- proposed RA option saying if you can do rs-refresh here's the periodicity
- routers should respond to unicast RS's with unicast RA's
- RS with unspecified source address?
- when router has a change, can multicast RA
- removing info is harder in RFC 4861
  - sleeping/unattached node might not see prefix deprecation message
- DNA doesn't even require revalidation
- Suresh Krishnan:
  - for efficiency, NS and RS probes can happen at the same time
- Sleeping hosts
  - DNA says unicast NS to old default router(s)
  - better to couple with RS refresh
  - can get new prefixes and other information
- RFC 4861 nodes without resilient-rs?
  - lost RS has to wait for 1800 seconds for periodic RA
  - could increase to 65535 seconds (6man-maxra)
- operational considerations
  - can I disable periodic multicast RAs?
    - if the network melts from this then there are other problems :)
    - likely not worthwhile unless controlled environment
- open issues
  - refresh time, 16bits -> 32bits?
  - update DNS to use RS/RA when RTO?
    - require sleeping hosts which ignore multicast RA to use RS refresh?
  - other optimizations when nothing changes
    - include epoch number in RA
- Lorenzo Colitti:
  - beware of "how before should"
  - the average environment doesn't need any of this
  - mobile devices actually transmit all the time (mail synching, ...)
  - reconciling all goals may be too difficult
  - why do anything?
  - EN: RS+RA serves as a protocol with an acknowledgement
  - hosts should refresh there information
  - multicast refresh
  - responses should be unicast
- Fred Templin:
  - update IPv6 over foo documents?
  - different link layers have different attributes
  - EN: this is a configuration knob, for environments that benefit, default
    is still RFC 4861 behaviour.
- Suresh Krishnan:
  - re LC: agreed,not a problem for mobile phones, but is a problem for
    sensor networks
  - sleeping mobile nodes do have issues
- Fernando Gont:
  - agrees to adoption
  - volunteers to review


Source Address Dependent Routing and Source Address Selection for IPv6
Hosts, draft-sarikaya-6man-sadr-overview-05 , Behcet Sarikaya, 15 min.
----------------------------------------------------------------------

- Behcet Sarikaya presenting
- sadr-overview draft, requesting adoption
- next hop issue
  - VPN is an issue
- next hop RA with a VPN router
  - (inscrutable network diagram, possibly a Picasso home network)
- seeking consensus on solutions
- should we define next hop option for RA? DHCPv6?
- Alex Petrescu:
  - VPN question: using VPN with IPv6? (Behcet: yes) Enterprise grade? (Behcet: yes)
- Brian Haberman (with AD hat):
  - we have a liaison statement, "looking into this"
  - they are not looking for us to define solutions
  - Behcet: I don't know what's going on in BBF
- Steven Barth:
  - mentioned PIO and 4191, but 4191 describes RIOs, what's up with that?
  - Behcet: what is the point? This is draft-pfister, so...
  - (confusion)
- Lorenzo Colitti:
  - How does the VPN router know what's going on inside the other networks?
  - Behcet: we assume that they know the next router in the home
  - what if my default router changes or I add a new one?
  - Behcet: maybe you're no longer on VPN, ...
- Ole Troan:
  - you're proposed 3rd party provides next hop information
- Alex Petrescu:
  - if this is for VPN, then VPN also has a mechanism to provide this info
  - RAs over a tunnel will send a source address of the VPN gateway not
    from the BNG or cellular gateway


Source Address Dependent Route Information Option for Router
Advertisements, draft-pfister-6man-sadr-ra , Pierre Pfister, 15 min.
--------------------------------------------------------------------

- Pierre Pfister presenting
- quick problem statement summary
- consequences:
  - bcp38 dropped packets || inefficient routing || redirect ping-pong
- new RA option, 4191 RIO + source prefix, SADRIO
- in classic RIO, add Ignore bit: if you're SADRIO aware you ignore the RIO
  for a SADRIO prefix
- host requirements:
  - include source prefix in (dest, router, interface) tuple
  - when sending do dest longest match, then source longest match, then
    router preference value
- router requirements
  - do not send multiple SADRIOs with same src and dest prefixes
  - do not send multiple RIOs with same dest prefix
- address some FAQs (why not just PIOs, why ignore bit, tlv alignment)
- 60 more lines of code in Linux kernel (first attempt)
- Suresh Krishnan:
  - I would like alignment
  - move all octets one to the left
- Behcet Sarikaya:
  - when I said PIO I should have said RIO
  - why change the name to destination prefix?
- Dave Thaler:
  - with 4191 author hat: I think you're doing the right thing, good work
  - recommend you define type D host: type C plus SADR
  - one multi-homed router giving to different prefixes is the harder design
    case, which this addresses satisfactorily
  - rule 1 says avoid unreach destinations, if an app specifies the source
    address then rule 1 can make use of this information
- Lorenzo Colitti:
  - agree with Dave
  - think we need this and this is what it needs to look like
  - does the implementation do config ipv6 subtrees? (PP: yes)
  - talking about rev'ing the hosts.  should we think of other things we
    might need before making protocol changes?
- Brian Carpenter:
  - I think we need something like this, but I think we need the overview
    document as well to describe what else is solved elsewhere and what is
    not solved
- Erik Nordmark:
  - haven't thought through all the different corner cases
  - some of the semantics can get hairy
  - decouple from RIO?
  - get some adjunct information from the routers, getting configuration
    information
  - PP: we want the application to pick the source address and having routing
    information is important
- Steven Barth:
  - compatibility with default router lifetime?
  - in a situation with only SADRIOs, we need a consistent way to disable
    default router lifetime
  - PP: agree
- Alex Petrescu:
  - don't have a specification for how the host behaves with source address
    routing selection
  - which default route would be chosen (for destination or source address)?
  - OT: this has been addresses in routing area
  - can we have CIDR on SADR?
- Dave Thaler:
  - host behaviour is something the document needs to cover and the working
    group needs to agree.
  - we should adopt this and work on the behaviour.
  - there are other ways this can work, but this shouldn't hold up a call
    for adoption
- Bob Hinden:
  - sounds like wg interest exists
  - should talk to AD(s)
  - not ready for call for adoption just yet


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

- Stefano Previdi presenting
- all together, 3 spring + 6man drafts
- define new routing header type, similar to RH0, "SRH"
  - contains segment list, policy list, HMAC flags
- multiple implementations, interoperability demonstrated
- adoption?
- Brian Carpenter:
  - worried that this thing inserts headers in the packet en route
  - not allowed by any other IPv6 specification
- Erik Nordmark:
  - the reason we don't insert header is that it inserts PMTU discovery
  - encapsulation is preferred
- John Brzozowski:
  - I disagree with Brian and others
  - we have valid use cases
- Lorenzo Colitti:
  - I don't know that inserting header is fundamentally against IPv6
  - currently not allowed, sure
  - not clear why it couldn't be allowed, assuming established rules
    - preserve header chain when existing the cloud
  - MTU is a red herring
    - we do this today in IPv4
    - a solved a problem, not that hard
- Erik Nordmark:
  - it works if you control the environment
  - you need to make sure ICMP errors don't leak out and go back to the host
  - if you can do encap you know you've provisioned enough MTU
  - if you get can ICMP error it will go back to the host
- Lorenzo Colitti:
  - example solution: MUST not emit such error
- Bruno:
  - this is in our charter
  - we will need some feedback
- James Woodyatt:
  - responding to Brian Carpenter
  - it's a theoretical concern
  - the headers your adding can be compressed
  - I think the idea of adding the SRH but when you insert (...out of time)
- Ole Troan:
  - interest of working on this?
  - hum, seemed to favor supporting this work


IPv6 Segment Routing Security Considerations,
draft-vyncke-6man-segment-routing-security , Eric Vyncke, 10 min.
-----------------------------------------------------------------

- Eric Vyncke presenting
- reworded:
  - within single ISP
  - not enable by default
  - ICMP generation
  - BCP 38
- RFC 5095 says benign uses of RH0 may be defined using future
  Routing Header specifications
- SRH HMAC coverage
- address concerns of RFC 5095
  - HMAC requires shared secret (controllar, SR-domain ingress routers)
  - how to propagate this shared secret is out of scope of this document
- Philip Matthews:
  - within single ISP, but multiple ISPs may want to do this
    (coordinating administrative domains)
- (name unheard)
  - maybe you need some encryption
  - source routing header from outside the domain should be trusted?
  - EV: there should be a trust relationship with the controller
-Jen Linkova:
  - re: topology disclosure
  - ICMP errors may include the SRH and expose topology
  - EV: traceroute would show you anyway
  - Stefano: if we have SRH, should we have a closer look at tools and
    see what we might need to change (same as MPLS)


Support for multiple provisioning domains in IPv6 Neighbor Discovery
Protocol, draft-ietf-mif-mpvd-ndp-support , Suresh Krishnan, 10 min.
---------------------------------------------------------------------

- Suresh Krishnan presenting
- info from mif document
- mif-mpvd-arch-11 includes IPv6 NDP proposal
- generic PVD container
  - RA can have multiple PVD containers
  - RS can request specific PVD container info
- proposed format
  - key hash (optional)
  - pvd_id (currently not specifically defined by mif)
- Dave Thaler:
  - legacy hosts will ignore the container option, like SADRIO
  - should limit permutations to not explode RA size
- Behcet Sarikaya:
  - maybe we put everything into this container option
- Steven Barth:
  - MTU issues with signatures
  - we might run into some issues
  - SK: don't have to have all mpvd info in one RA, can send 1 RA per
    mpvd container
- Christian Heuitema, Microsoft:
  - draft needs a privacy analysis
  - a host may disclose pvd ids, which has privacy implications
  - SK: agree


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

Current issues with DNS Configuration Options for SLAAC,
draft-gont-6man-slaac-dns-config-issues , Fernando Gont, 5 min.
---------------------------------------------------------------

- Fernando Gont presenting
- RDNSS, DNSSL, with lifetimes
- found to be too short
  - packet loss can cause DNS info to timeout
  - failure scenario is implementation dependent
- propose to change default lifetime value, and semantics
  - can keep expired info if it's the only info you have
  - hosts may also use active probing with RSes


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

- Fernando Gont presenting
- RFC 7045 for IPv6 options
- clarify default processing for IPv6 options


Improving Scalability of Switching Systems in Large Data Centers,
draft-zhang-6man-scale-large-datacenter , Ming Zhang, 5 min.
-----------------------------------------------------------------

- Zhang presenting
- 2 million IPv6 end hosts
- option 1: multiple clusters
- option 2: large FIB table on the spine
  - keep leaf FIBs smaller
- propose scale through aggregation
  - cluster id bits (8 bits)
  - switch id bits (16 bits)
  - host id bits (32 bits)


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

- Sheng Jiang presenting
- copy received flow label into response
- application scenarios described
- security concerns:
  - flow label is untrusted
  - can be forged
  - man-in-the-middle attach
  - consider to be useful only within single administrative domain



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