Minutes for V6OPS at IETF-96
minutes-96-v6ops-1

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 , <draft-ietf-v6ops-unique-ipv6-prefix-per-host>
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, <draft-anderson-v6ops-v4v6-xlat-prefix>
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,
<draft-bowbakova-rtgwg-enterprise-pa-multihoming> 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%