Minutes for V6OPS at IETF-95
minutes-95-v6ops-5

IPv6 Operations - IETF 95 14:00-15:30 April 4
Chairs: Fred Baker, Lee Howard
Minute taker: Ole Trøan
Jabber scribe: Mikael Abrahamsson, Alejandro Acosta

Chairs: Introduction of agenda.
No comments on the agenda.

Operational Implications of IPv6 Packets with Extension Headers
        <draft-gont-v6ops-ipv6-ehs-packet-drops>

Pause while waiting for the slides.
Fernando Gont presenting.

Eric Vyncke: Positive document. My question: How did you get the content of
this document? FG: We talked to several operators. I can't claim this is the
opinion of the operators. EV: Did you this document on NANOG or RIPE mailing
lists? FG: Not sure, I usually do that.

Fred Baker: A HBH header can force a packet to a different path (slow path).
That issue is being looked at in 6MAN. If I find a HBH option in the packet and
the only option is the pad, and hardware forces the packet off the path, is a
DOS attack. How does enforcing a maximum length of the packet help here? FG: If
the packet is short enough it can be processed in the fastest path. You have to
resort to software processing. *Discussion on enforcing cap on extension header
chain*

Mark Townsley: Interesting that in an operational group you have a long
discussion about how to design ASICs in the forwarding plane. Why would we try
to encode limitations on hardware that exists right now?

FG: We try to make it clear that if you operate outside those boundsthen
thingss don't work.

Joel Jeaggli: It isn't as much that we design ASICs. I did realise this morning
that my understanding was from routers built in 1998. Perhaps we can parse the
header longer, we're also making some assumptions what we have today and what
we have in the near future. The future looks like a lot like the near present.

Mark Smith, remote:
  Our imagination is limited and is currently constrained by what we have done
  and shouldn't indicate what we can do in the future."
Question is, are E.H.s the right tool for these problems people are solving.

Mark Townsley: Our imagination is limited. Let's not put any hard scalbility
bounds in protocols. A hard scalability bound is like a 32 bit address or a
640kB limit. RFC5281.

Joel J: We shouldn't take the blame for the protocol designers, and if there
are problems we should talk about them, cause we are operators.

Bob Hinden: The way I think about is, is to create limits about how things work
today is going to hurt us later. We should not provide guidance of how things
work now, that might change 5 years in the future.

Fred B: What advice can you give Fernando G on what would be useful in this
document?

Tim Chown: Think this is useful. The first two points in the action plan about
more granularity in filters and advice on filtering is useful, you should be
more careful about the cap of length of extension headers. "The longer you make
the extension headers the higher drop probability they have." FG, TC discussion
on a concern about putting a number on it.

Lee: Close the mike soon.

EV: The last one is a snapshot in time, I consider this not a good way to go
forward.

Mikael Abrahamsson: Filtering instead of being dropped.

Mike Ackerman: This is necessary, to make things work well. Encourage hardware
vendors to be able to parse further.

Mark Townsley: Imagine 15-20 years ago, there seems to be lots of router that
only supports one MPLS label, then you would never had VPNs or loop avoidance,
all the cool things you can do with multiple labels. This is a self correcting
problem. If operators want to give advice to vendors, then give advice to be
more flexible.

Fred Baker: What guidance does the WG give to Fernando? I saw three consensus
operating. I don't think we can take this as a WG document now. What does the
WG like to see in this document, so there is good guidance to 6man / vendors?

Tim Chown: We seem to have some sort of consensus in the room, what are the
reasons for not adopting it?

FB: Part of the issue is Bob's comment about this being a self correcting
problem.

Tim Chown: If we took out the 3rd point would it be more acceptable?

FB: There is a draft in opsec.

Fernando Gont: The discussion is that you shouldn't go and look deeply into the
packet.

Mark T: I'm frustrated by all three of these. If we don't think we understand
what we can do in the future, you want to filter something for security reasons
or for policy reasons.

Ole T: It is paradoxical that one working group is writing protocol
specifications and another IETF working group is writing recommendations to
break those protocols.

Christian H: A license to drop packets.

Tim Chown: Simple security is a counter example.

Lee Howard: Operator hat. We can provide guidance. I have a network, sometimes
I can drop packets, because routers fall over for certain packets.

Lee Howard / Ole Troan: We are allowed to say something, I can't ever say that
we will never drop a packet. OT: But we shouldn't make recommendations based on
vendors bugs, or operator policy.

Fernando G: When we see  a high drop rate from measurements, the impression was
this was because of operator faults. They don't know what they are doing, but
they do know what they are doing. The only option they have is that they drop
these packets. There is a reason for them to do this.

Lee: Chair hat on, looking for working group consensus. Is there more that need
to happen to the document before that can happen?

Mark T: Why did we separate the reasons from the results?

FG: This is from talking to operators. This explains the intention behind the
drops.

Fred B: I need to bring this to a close. We need to take this to the list. We
don't see consensus on the list. The guidance that you have been given today,
is please don't think of limits, but rather what you want supported. We have to
take it to the list at this point.

Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node
Group Membership
        <draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node>

* Lots of audio problems *
Mark Smith presenting

Eric Vyncke: Rotuers and switches don't listen to MLD.
Mark Smith: <garbled>
Dave Thaler: I understood the intent. Very good presentation and good thing to
think about.

Ole Troan: SAVI and efficient ND / address registration are alternatives.

IPv6 deployment in LAC: successful and not so successful stories
LACNIC report on IPv6 deployment in Latin America

Presenter: Guillermo Cicileo

Fred Baker: Difference between IPV6 ready and IPv6 CPE customer?
CG: If the ISP is able to deliver IPv6 to the customer versus customer having
IPv6 ready CPE.

Barbara Stark: You said the CPE was not IPv6 ready. By that do you mean that
they use UNH IOL IPv6 ready and comply with RFC6204 and still not work?

CG: When they say it is not ready, when they did testing, not all the features
work. E.g. prefix delegation or combination of configuration don't work. They
don't have to update the firmware or make some changes to equipment.

Tim Winters: Two things. We are seeing a change, we have seen problems in the
past .