v6ops minutes
Note taker: Alain Durand
Agenda
short discussions, 4 presentations
Status
docs sent to IESG:
draft-ietf-v6ops-onlinksuumption, draft-ietf-v6ops-vlan-usage, draft-ietf-v6ops-natpt-to-experimental
experiment: use someone that was an ex-RFC editor to help fine tune the document
5 documents that have been through wg last call and need decision on what to do
other documents need discussions
Short discussions:
Draft-ietf-v6ops-ipsec-tunnel
7 people read it. Few says ready to go.
Kurtis: not much support. By default , it need more support to go to IESG.
Call again: 9 for sending the doc to IESG
Merike: ESP/null encryption vs AH... Question the decision to make ESP/null a MUST
and AH a may.... Issue: threats against the header (not covered by ESP/null)
Graveman: ESP is mandatory is 2401 bis. No issues where there is a real attack on the
header.
Fred: configuration guidance or implementation guidance in the draft?
Pekka: configuration guidance
Fred: Merike may have a legitimate concern, but this is a comment on 2401bis,
this issue should be brought in the security community and then v6ops will act on this
if need be.
Thaler: clarification: some extension headers may be attacked by man in the middle.
Pekka: we are talking about v4 encaps, we may not care about them
Fred: some people do care about v4 options...
Chairs: conclusion: the doc is ready to go
Draft-ietf-v6ops-security-overview
2 people read the update
Chair is going to take them to the list and ask people
Draft-ietf-v6ops-nap
20 people read it.
Ready to go to IESG: most says it is ready to go, few don't care
BB-deployment
In Paris, docsis community said it was going to change things
and was going to produce comment. No comments received yet.
Alain: clarification on the docsis process, need to reach internal milestone
before issuing public statement, that milestone was not met before the
draft cut-off date.
Who read it: 10 doc
Ready to go (about the docsis case) 7
Prefer to hold/no opinion: 2
Enterprise analysis doc
Remaining issue: the use of the term DSTM
Fred: DSTM; reference to an experimental doc, dual stack: generic term
IETF should not recommend an experimental tool
Jim Bound: DSTM is a large effort outside of IETF.
More docs will be submitted to experimental track.
There is a precedent in IETF to refer DSTM (unmanaged doc)
Pekka's has lost the debate on the list (no one supported him)
Fred: RFC2026 says an experimental document is not done, you are not allowed to
make recommendation in PS doc to tools in experimental doc.
Jim: Tim Chown proposed to change wording to say "DSTM is an example..."
Kurtis: This would be ok
Fred: ok
David Kessens: AD hat on. No problem making an example.
Question: does the wg think is is a "good" example?
Pekka: DSTM spec is not enough to describe what need to be implement...
The doc should say which exact feature requires DSTM?
Fred: would referencing DSTM among other examples be ok?
Answer: yes
Who read it: lots
Ready to go: lots. Not ready: 1 (pekka)
Pekka: issue with critical infrastructure appendix
Jim: authors are not willing to remove it
Action Item: Jim to send text to the list about DSTM as example,
and then the chairs will issue a wg last call.
Fred will send mail to the list to get comments on:
Draft-kim-v6ops-ipv6overwibro-issues and
Draft-lee-v6ops-natpt-mobility.
Draft-blanchet-v6ops-routing-guidelines
Alain: not enough delta from what was made in NGtrans for the 6bone.
This would be better handled in the RIPE, NANOG, APRICOT community
Pekka: IETF had a mandate to make recommendation for the 6bone experiment,
IETF has no mandate for the larger community
Jordi: this would be useful in v6ops.
Draft-baker-v6ops-end2end
Purpose was to generate discussion, not much discussion happened...
Fred: RFC1958 connectivity has is own reward. This gets broken by
IPv6-only / IPv4-only networks.
Question: is this an issue or not?
Pekka: agree with concerns, issues will come up.
-00 not concrete enough to reach the audience
Tony Hain: the issue is when the infrastructure gets fragmented
Elwyn Davies:
Alain: this goes back from the original IPv6 design decision to make IPv6
not backward compatible. You have the choice: dual stack, NAT or live
with fragmentation. It will be good to document what breaks if you decide
to fragment the infrastructure
Fred: summary: a document saying stupid things are stupid will be good
Port scanning (Stig )
Overview of the draft
Can we adopt this as wg item?
Pekka: useful work. Concern: wg has 5-10 active docs, not much activity happening,
wg should focus on current docs first.
Dave Thaler: this is about address scan, not port scan.
12 people read the current doc
About same think the doc is sound, 5 people are willing to contribute
Chairs: ok to accept as wg doc
6 in 4 versus 6 over 4 (Jordi Palet)
Issue: confusion between 6in4, 6over4, ipv6 in ipv4,...
Draft: clarify that x in y means encapsulation,
x over 4 is referencing a particular transition document
Hesham: an ietf doc will not help people who do not read ietf doc
Kurtis: (chair hat off) echo Hesham concern
Tony: it is going to be d
Alain: the real issue is confusion with 6to4, people think is is NAT Ipv6 to IPv4
X over Y is a very generic terminology. Don't change it, revisit the 6over4 document
Pekka: echo Alain's comment
Brian Carpenter: (author of 6over4) the genius is out of the bottle, difficult to fix it
Fred: the right way to handle may be an article in wickopedia
Who is in favor of wickopedia: all room. Who in favor of IETF doc: zero
IP in IP tunnel MTU assurance (Fred Templin)
Draft presentation
Tunnel mechanisms have no means of assuring tunnel MTU
Issue: IPv4 fragmentation is bad, IPv4 path MTU is not reliable (NAT, Firewall)
List of requirements
Dave Thaler: assurance might be too strong a word, we have no assurance
on Ethernet for example, this is best effort.
Fred: best effort is what is meant, need to define the terminology
Dave Thaler: this should be reviewed by the pmtud wg
Pekka: see some potential problems, maybe not as bad as author sees.
Would be interested in working on this if this was done in the venue that
will work on the solution
Fred: what would be the correct venue? Pmtud?
Pekka: maybe, need to look again at their charter
Dave Thaler: pmtud is the right place with the right expertise,
may require a charter update. Documenting the issue in v6ops
(and separating the requirement) is the right thing to do
Alain: the purpose of v6ops is to document operational issues,
so this document belongs here
Thomas Narten: Softwire may be the right place to fix the problem
pmtud is focusing on TCP, this is a generic tunneling problem,
so softwire might be a better place.
Fred: go talk to chairs of pmtud and chairs of softwire if they want to take it.
If this remains an issue, go back to v6ops and we will see with AD what to do
BCP for filtering ICMPv6 messages (Elwyn Davies)
Updated as wg draft, include suggestion received
To do list: add example of firewall rules
Fred: look for comment of the list, then will issue a wg last call.
|