IETF96 – Berlin, Germany Chairs: Fred Baker, Lee Howard 21st of July, 2016 14:00-15:30 Materials: https://datatracker.ietf.org/meeting/96/materials.html/#v6ops Agenda: https://tools.ietf.org/wg/v6ops/agenda Jabber: Mikael Abramsson, scribe. Log at https://www.ietf.org/jabber/logs/v6ops/2016-07-21.html Minutes: Éric Vyncke, with help from Nathalie Trenaman, Musa Stephen Honlue Unique IPv6 Prefix Per Host 2016-07-08 , Presented by John Brzozowski Main updates: removing the captive portal part and moving it to another I-D. A -02 is targeted for IETF-97. Lorenzo Collitti: should we consider a specific bit PIO to signal this feature (a dedicated prefix)? Then, a specific document requesting this bit should be addressed to 6MAN. Mikael Abrahamsson: previously brought this to 6MAN. JJB: ask to provide with the text even if very crude. 64::/16: An IPv4/IPv6 translation prefix 2016-06-20, Presented remotely by Tore Anderson (with some Meetecho issues at the beginning) Tore explained his proposal (read the I-D) and thanks David Farmer for his suggestion Dave Thaler: 64::ff9b::/96 is check-sum neutral, so, please add text about check-sum neutrality. Tore: actually, it is not relevant for RFC 6052 only for RFC 6051. Lorenzo: check sum neutrality is really important way beyond and some translation technologies will have to drop the packet because check sum cannot be recomputed Lorenzo: RFC 1918 is not unique globally hence the specific rule why RFC 1918 cannot be used with 64::ff9b:: should add some text about this Lorenzo: the /16 is probably too large (Tore: because RFC 6052 specifies some prefix sizes), Lorenzo: why not using the operator’s globally unique address space? (Tore: easier to distinguish between native/internal IPv6 addresses and addresses which are from IPv4/outside). David Schinazi: T-mobile does not use the well-known prefix and use its own address space, so, David guess that every provider does the same. Jen: sometimes using own address space is complicated (such as writing ACL) but a /16 is way too large. Pierre Pfizer: could also be ULA 😉 and wonders why is it so important to have a well-known prefix for NAT64 Dmitry Kohmanyk: could use a /64 and keeping the check-sum neutrality David Lamparter: could indeed have several NAT64 prefixes David Schinazi: gives some explanations about why NAT64 uses a /96 (to glue of a IPv4/32 at the end) and wonders why there are other lengths in NAT64. Fred, because CERNET (Chinese NRN) wanted to put the IPv4 address in the middle of the address because they want to interconnect some Universities. Mohamed Boucadair: check-sum neutrality is important only for one side of the TCP connection Tore: could change into a /48 still allowing multiple /64 David S: this would be better, still unsure he sees any value but why not? Apple has done extensive testings for NAT64 and they noticed that some app developper hard coded the prefix used by the Mac NAT64 (probably because the app does not rely on DNS hence no DNS64). Brian Carpenter: beware RFC 6890 will be changed Lee Howard: suggests that Tore revise based on discussion, then we go through the list Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution 2016-07-05, Presented by Jen Linkova The I-D was already discussed on Tuesday in RTG area, it addresses the multi-homing issue when each host has multiple prefixes from multiple providers and needs to select the right uplink (to avoid BCP38 issues). Or because the host wants to select a specific prefix (cost, bandwidth, ...). Source Address Dependent Routing (SADR) can be used to handle multiple uplink. But, how can a host select the right source prefix? SADR incremental routing can be done but not optimum and may require tunnels to avoid loops RFC 6724 for source address selection especially rule rule 5.5 "prefix addresses in a prefix advertised by the select next-hop to reach destination" (alas this rule is not always implemented). SAS can be influenced by DHCP (labels table distribution RFC 7078 but not widely deployed), RA (next-hop & preferred vs deprecated addresses) or ICMPv6 (incorrect source address). A specific RA option could be use to link a PIO to some destination address. OR a router can appears as multiple virtual routers sending different RA (containing different PIO or even RIO for specific destinations). An uplink can be signalled by sending one virtual RA with router lifetime = 0 (and keeping the RIO active). Jan Zorz: when a router dies, then it won't be able to send any updated RA. Jen: in this case, the uplink router is different that the access router. ULA can be used as a stable prefix when all uplinks are down. Lorenzo: what will happen if hosts do not support RIO & Co... but several use cases are really important. Brian Carpenter: 6MAN has just issued a document which describes what hosts should do (multi-homed) and RFC 3582 (describe multi-homing goals). Chris Bowers: unsure whether we should align on an old RFC. Brian does not agree. Pierre Pfizer: the new 6MAN document addresses only the first-hop, there is also some confusion between SADR (here source is looked first, then destination while SADR is first destination then source) and policy routing, the complexity of the proposed virtual routers seems to indicate that there should be other solution to be designed. Dave Thaler: great work Benedikt Stockebrand: for SMB network, this configuration requires a lot of expertise which is not commonly available in SMB. Should be plug and play. Jen: I agree. David L.: or use HOMENET  David L.: I-D could be improved by removing some texts Tim Chown: good job, RFC 7078 the original idea is to send stable long-term information. Propose to do SADR in RTG area and to do host communication in V6OPS (and perhaps 6MAN). Philipp Tiesel: unable to understand the point about Linux multiple routing tables and DHCP daemon. Chris Bowers: splitting the work load among WG, prefers not to do it to keep the justification of SADR to educate RTG area. Dave L.: should we split and write hosts requirements towards to the routing system? Fred Baker: there are other ways than full SADR so there is little need indeed to put it in the I-D Barbara Stark: routers could provide information about uplink, latency, ... Geoff Huston: SHIM6 is dead because ISP do not want to give customers/end-users freedom to host to select their path.... they want to keep their traffic under control. IPv6 Deployment Survey, Jordi Palet Survey about how ISP are deploying IPv6. 40% of ISP used IPv6 to fill in the survey. 900 responses in 2 months. Graphs were too small to read and take any note 😔 Most deployments are dual-stack 75%