Minutes IETF99: v6ops
minutes-99-v6ops-00

IPv6 Operations - IETF 99

13:30 Thursday 20 July 2017

--

Reporting of Happy Eyeballs v2 Failures
2017-07-03, <https://tools.ietf.org/html/draft-palet-ietf-v6ops-he-reporting>
Jordi Palet Martinez

Fred Baker: We don’t define protocols here. This belongs wherever syslog work
belongs.

Waren Kumari: Asking for a well-known anycast address is not really defining a
protocol.

Eric Vyncke: What is the incentive for anyone to implement and/or deploy this?

Ondrej Caletka: This won’t work without NAT64 Jordi Palet Martinez: This does
not need NAT64 or DNS64

Ondrej Caletka: This will interact badly with lingering uses of 6to4 Jordi
Palet Martinez: But 6to4 is deprecated Waren Kumari: That doesn’t mean no one
is still using it

Waren Kumari: There’s a big DOS vulnerability here

Jen Linkova: I see very limited use for this. Perhaps within an enterprize
network.

David Schinazi: Syslog messages of IPv6 failures may have serious privacy
implications Private web browsing may not be private if your client device is
logging failures into an unknown syslog server We should not try to integrate
this into RFC6555bis; RFC6555bis document is almost done; this still has a long
way to go

Mikael Abrahamsson: The idea here sounds useful, but there are a lot of details
to work out

--

Considerations For Using Unique Local Addresses
2017-03-13 ,
<https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations> Bing Liu

Merike Kaeo: Why are we even discussing ULAs?

Fred Baker: A ULA is a firewall rule implemented in BGP I don’t understand the
opposition to ULA

Lorenzo Colitti: ULA can create a false sense of security If you’re on an
adjacent network, just because I don’t advertise a route doesn’t mean you can’t
send a packet to me

Erik Kline: Good that the document states that ULA addresses are not RFC 1918
addresses

Document needs to say ULA + NPTv6 is “not recommended” or “NOT RECOMMENDED”

Tim Chown: Many people do seem to use ULA without trouble.

Ronald Bonica: This document can be shortened to just a couple of pages.

Victor Kuarsingh: I agree: Document needs to say ULA + NPTv6 is “not
recommended” or “NOT RECOMMENDED”

Lorenzo Colitti: Lots of existing walled gardens work fine using GUA global
addresses

Tim Chown: UK universities are creating ULAs manually, instead of including the
random part

Victor Kuarsingh: I agree with Lorenzo.

Marcus Keane: We find it’s better to use GUA global addresses instead of ULAs

--

Using Conditional Router Advertisements for Enterprise Multihoming
2017-06-14 , <https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras>
Jen Linkova

Fred Baker: I’m trying to work out how to implement this

Timothy Winters: Why not use route information options?

Jen Linkova: Not all platforms support RIO

David Lamparter: I support this and plan to implement it Do the policy rules
need to include more than just checking the routing table?

Tim Chown: Could some external device monitor the network and send commands to
the routers?

Jen Linkova: It’s better if the routers do this detection for themselves

Lorenzo Colitti: It is useful for us to document the current behaviors of
today’s hosts which may have software from ten years ago. This is what
operators need to know.

Waren Kumari: Most implementations do VRRP tracking already, so this could be
done in a similar way.

Thaler: What if both uplinks are down? Leave both deprecated.
Both addresses still exist; they’re just not preferred.

Mikael Abrahamsson: There is prior art here.
RFC 7084 talks about what to so when WAN link goes down.
The Homenet code already does something like this.

Timothy Winters: We should add RIO too, for future hosts that support RIO.

Mikael Abrahamsson: I would like to see more work on the control plane

Jen Linkova: This mechanism is independent of the control plane that controls it

Darren Dukes: How fast is the propagation?

Jen Linkova: That’s hard to say right now because of vendor bugs.

Pierre Pfister: I support this. This work is compatible with RFC 7084 and
Homenet work.

Lorenzo Colitti: Helping to get vendor bugs fixed is a good reason to publish
this.

David Schinazi: I like this work and support it.

Fred Baker: Call for hum on adoption

Reject outright? Silence
Consider later?  Weak hum
Adopt now?       Strong hum

--

Requirements for a Zero-Configuration IPv6 CPE 2017-06-17,
<https://tools.ietf.org/html/draft-baker-v6ops-cpe-autoconfigure> Fred Baker

Bob Hinden: The router I have is less of a horror story

Timothy Winters: We should make having IPv6 enabled by default a requirement
for using the “IPv6ready” logo

Barbara Stark: The only significant IPv6 success stories are when the ISP
provides its own home gateway, already configured correctly

Jordi Palet Martinez: Look at RFC 8026

Lorenzo Colitti: The document is overly detailed.
We want implementers reading and complying with RFC 7084.

Hans Liu: D-Link is working to improve this issue

Victor Kuarsingh: I have never seen a router that comes with IPv6 enabled

John Jason Brzozowski: We should include a specification of what a router
should do if it gets no IPv4 address.

Joseph Abley: D-Link currently has a line of 31 different home gateway models,
all with IPv6 enabled by default

Barbara Stark: AT&T-supplied home gateways do IA PD.

Mark Townsley: D-Link was involved with World IPv6 Launch in 2012.
Initiatives like that are needed, not only more RFCs.

Fred Baker: What are next steps? Sorten the document?

No specific actionable conclusion was reached.

--

RFC 7984-bis in four parts
Basic Requirements for IPv6 Customer Edge Routers
2017-06-12 , <https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis>
Transition Requirements for IPv6 Customer Edge Routers
2017-06-12 ,
<https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-transition> Minimum
Requirements for IPv6-only Customer Edge Routers 2017-06-11 ,
<https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2> Basic Requirements
for IPv6 Customer Edge Routers with HNCP 2017-06-11 ,
<https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis4-hncp>

Jordi Palet Martinez

Barbara Stark: We should be wary about updating RFC 7084 unless we really need
to

Timothy Winters: S-2 (ingress filtering) was a “MUST” in RFC 6204, but got
downgraded to “SHOULD” in RFC 7084. We should revert that to “MUST”

Mikael Abrahamsson: I agree with Barbara Stark.
We should not update RFC 7084. We should have a new RFC for transition
mechanisms.