SUBMITTED version 1.0  15 August 2003
=======================================
IPv6 Operations WG (v6ops)
IETF-57, Vienna

Tuesday, July 15 at 1545-1800
Wednesday, July 16 at 1530-1730

======
CHAIRS:

Bob Fink <bob@thefinks.com>
Pekka Savola <pekkas@netcore.fi>
Margaret Wasserman <mrw@windriver.com>

The minutes were edited by Bob Fink from various notes from 
attendees.

There were over 200 folk in attendance.
===========================
Administrative information:
v6ops discussion: <v6ops@ops.ietf.org>
Subscribe to v6ops mail list: <majordomo@ops.ietf.org> "subscribe v6ops"
v6ops mail archive: 
<http://ops.ietf.org/lists/v6ops/>
v6ops web site: <http://www.6bone.net/v6ops/>
v6ops Project Status: 
<http://www.6bone.net/v6ops/
v6ops_project-status.html>

=======
Agenda:

Introduction and agenda bashing - 5 mins, Margaret Wasserman

current status - 5 mins, Margaret/Pekka

UNMAN Analysis discussion - 25 mins, Christian Huitema

Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet

IPv6-IPv4 Translators in 3GPP Networks - 10 mins, Karim El-Malki

ISP Scenarios - 40 mins, Mikael Lind

ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound

v6-on-by-default - 25 mins, Alain Durand
   5-10 mins presentation, remainder discussion

threedegrees - 10 mins, Christian Huitema

Security - discussion of what we should be doing - 45 mins, Chairs

NAT-PT Applicability Statement team report - 15 mins, Peter Barany

Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka Savola

Status report of IPv4 Survey drafts - 10 mins, Chairs

========
Minutes:


===================================================
First Session:  Tuesday, July 15, 2003 at 1545-1800

===================================================
Introduction and agenda bashing - Margaret Wasserman

===
current status - Margaret/Pekka

<http://www.6bone.net/v6ops/v6ops_project-status.html>

<http://www.ietf.org/html.charters/v6ops-charter.html>


SLIDES:

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/v6ops-status.pdf>

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/v6ops-status.ppt>

Margaret reviewed the status of the v6ops projects and various 
activities (see the v6ops web sites and slides above).


===
UNMAN Analysis discussion - Christian Huitema

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-unmaneval-00.txt>

SLIDES:

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/unman-analysis.pdf>

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/unman-analysis.ppt>

Christian presented on the Unmanaged Network Analysis draft (see slides and 
draft above) ending with a summary of his recommendations:
  Develop and standardize Teredo or similar technology
  Agree on standardized IPv6 prefix delegation mechanism
  For "informal prefix sharing", develop a standard way to perform "RA 
proxy", possibly as part of a "multi-link subnet" specification
  Standardize a way to provision a DNS resolver address in IPv6 only hosts
  Proceed with the standardization of LLMNR
  Continue standardization of 6to4
  Standardize an IPv4 over IPv6 tunneling mechanism, as well as the 
associated configuration services

Christian believes the next steps are to:
  WG last call for evaluation document
  Act on recommendations

Rob Austein said that, as a design team member, he didn't remember 
recommending teredo.

Alain Durand felt that the scope of the document is not to recommend 
specific technology, e.g., teredo, rather to point out there are holes in 
IETF specifications that need filling.

Erik Nordmark asked why prefix delegation isn't sufficient?  Why is RA 
proxy also needed?

The chairs noted that this item should be taken to the list, and v6ops may 
not be the right place to decide.

Margaret noted the lack of mailing list feedback on the draft.

Erik Nordmark asked if the decision for IPv6 over NATed networks should be 
made.

Margaret felt that there should be an interim meeting for this issue.

Tim Chown asked why 6to4 was proposed instead of tunnel brokers?

Christian replied because 6to4 does not need much configuration nor a 
subscription.

Tim noted that the tunnel broker user experience seems to be more 
predictable.

Marc Blanchet felt that the tunnel broker does not get a fair chance in the 
analysis draft. Christian replied that there has not been enough time to 
incorporated the tunnel broker work.

Marc asked if he committed to add the tunnel broker to the analysis 
draft, to which Christian replied that he was only making a 
commitment to discuss and evaluate.

Erik Nordmark noted that there is tension between configuration and 
no-configuration solutions. Too much automation may be bad as it is 
difficult to debug. This has not been sufficiently discussed. 
Christian replied that there has to be a way out of the automatic 
mechanism if it fails.

Marc Blanchet noted that the freenet6 tunnel broker proposal has never been 
given a chance to be reviewed, which he felt was unfair.

Tony Hain said that the discussion is not in the right context here. This is 
not a problem for unmanaged networks but for enterprise networks.

Bill Sommerfeld asked why is it that the security implications are just for 
v6 and not for v4. Christian noted that v4 is often behind NATs and thus a 
little bit more protected.

Bill replied that this was not true. However, he will send the text to 
Christian to explain what is needed to change in the text.

Rob Austein stated that help is needed for the analysis document. It is 
still fairly new, and does still need work.

Margaret noted that while the scenarios draft has been sent to the IESG, the 
analysis draft still needs work. She then asked how many people have read 
the doc, noting that she didn't see many hands, and that people should read 
and comment on the draft.

===
Forwarding Protocol 41 in NAT Boxes - Jordi Palet

<http://www.ietf.org/internet-drafts/dr
aft-palet-v6ops-proto41-nat-00.txt>

SLIDES:

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/prot41-nat.pdf>

Jordi Palet presented his draft on forwarding protocol 41 in NAT boxes (see 
draft and slides above). The basic premise is that this behavior is not 
documented, though it is widely used. Jordi noted that there is no need for a 
new transition mechanism.

Christian Huitema commented that he had looked at this approach a few 
years ago. However, it does not scale beyond one computer behind the NAT. 
Jordi replied that it isn't intended to be a general solution, and may not be 
the right for a totally unmanaged network. There may have to be a PC based 
router behind the NAT.

Christian noted that though it does work in very restricted cases, it 
isn't really applicable to unmanaged networks.

Pekka Savola commented that it is clear that it does not work for many 
cases.

Rob Austein also thought that here are already applications like this.

Bob Hinden felt it would be better to recommend that they have v6 in the 
NAT.

Keith Moore (through Jabber) commented that he thought it better to have 
6to4 in the NAT.

Tim Chown noted that this solution could be added to the current NATs as a 
simple firmware update.

Christian said that there are many NAT vendors are implementing 6to4 in the 
NAT. It is actually bad to recommend the protocol 41 as you will confuse the 
NAT vendors.

Jordi felt that this could be a possible "second choice" for NAT 
vendors.

Itojun stated that this should not be recommended, but this current 
practice should be documented.

Alain Durand asked if this solution is compatible with 6to4 in the NAT box? 
Christian replied no.

The chairs felt that there should be more discussion on the list as to what 
should be done about this document.

===
IPv6-IPv4 Translators in 3GPP Networks - Karim El-Malki

<http://www.ietf.org/internet-drafts/dr
aft-elmalki-v6ops-3gpp-translator-00.txt>

SLIDES:


<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/3gpp-translator.pdf>

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/3gpp-translator.ppt>

Karim El-Malki presented his IPv6-IPv4 Translators in 3GPP Networks draft 
(see draft and slides above).

Someone commented that STUN doesn't work the way Karim proposed.

Gonzalo Camarillo commented that the Sipping WG has worked more on v4 and 
NAT. v6ops has the knowledge on v6ops. There is no place  to start the 
work.

Margaret stated that it may be better to have this in the sipping wg as it 
raises the v6 awareness there, and to give support there for IPv6.

Peter noted that the NAT-PT part could be useful.

Margaret asked what is the relation of this and the 3GPP analysis 
document? Jonne Soininen replied that the analysis document hints that 
something is needed, but the actual solution has not been done there.

What action, if any, is needed next?

===
ISP Scenarios - Mikael Lind

<http://www.ietf.org/internet-drafts/dr
aft-lind-v6ops-isp-scenarios-00.txt>

SLIDES:

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/ISP-scenarios.pdf>

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/ISP-scenarios.ppt>

Mikael Lind presented the ISP Scenarios team's draft (see draft and 
slides above), noting that the team had started over with new draft, an 
that it was a further simplification of the arlier team effort.

It defines a generic ISP network and stages of maturity, with 
transitions between stages, but was limited in detail, omitting v6-only 
networks

Dave Meyer asked how sensitive is the analysis? He noted that there is some 
movement to collapse edge-to-core networks. Mikael noted that the team was 
talking about DSL modems, etc, not real access routers. That the focus was on 
ISPs, not all coexistence mechanisms, and asked if the team should write a 
guide for ISPs, i.e., refocus the intent of the documents.

Alain Durand asked if we can really design a generic network? We have 
already deployed IPv6 in some networks - should we document what they did? 
Mikael replied that although people have deployed, have they deployed in 
production networks?

- Should we talk about different kinds of networks (DSL, cable, etc.)? how to 
transition my IGP?

- Should we end this work? Is there enough ISP interest to justify the 
work?

Pekka Savola noted that it was very simple and general at this point - is 
that OK? Is it sufficient?

Margaret asked to hear from ISPs?

Kurt Lindqvist commented that ISPs differ a lot. How many ISPs have 
deployed v6 with same SLAs as v4?

Dave Meyer noted that this is the same as MSDP - go document the 
problems people were having in deployment instead of doing a 
comprehensive guide of all possible scenarios.

Shin Miyakawa noted that it is difficult to define transition path for the 
NTT backbone, that they can think about anything, but 
administration may limit them. Some routers can do what we want, others 
can't. Eventually this will change. Some parts of network are SONET, some 
are MPLS - there are lots of technologies inside our networks!

Carl Yeager said that from his ISP point of view, we need a lot more 
details about the applications required for the transition. Document is 
nice but doesn't help small ISP migrate. Should this happen at NANOG or 
similar? It's a FAQ, not an RFC... that this is more like a tutorial on 
IPv6 than an ISP document - not sure that's what we need.

Brian Carpenter commented that we did this to find out if we were 
missing any transition mechanisms. Margaret further noted that we need to 
know how operators will actually deploy v6. Pekka felt that our charter 
does include documenting operational practice.

Margaret asked how many ISPs think v6ops should do this work? There was 
some support shown.

How many are willing to help us? Some.

How many people have read the draft? Some.

How many people are ISPs in the room? Quite a few.

How many can help? Some.

The chairs asked for interested ISP folk to come to them after the 
meeting and volunteer.

===
ENT Scenarios - Yanick Pouffary/Jim Bound

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-entnet-scenarios-00.txt>

SLIDES:

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/enterprise-scenarios.pdf>

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/enterprise-scenarios.ppt>

Yanick Pouffary presented an overview of the Enterprise Scenarios draft 
(see draft and slides above). She especially noted that there had been much 
recent reworking of the draft to accommodateds team input and that the team 
now felt that it was time for it to be accepted as a wg draft.

Also of special note was that 3 base scenarios are defined to capture the 
essential abstraction set for the Enterprise. That it should be noted 
that:
  There are definitively more scenarios
  We cannot possibly cover all of them
  We selected the most representative ones

Yanick also said that the team will write a revision to the scenarios 
document for the next IETF, that there is still work to do on this 
scenarios doc but we need to hear from the wg on the mail list. She also 
thanked Alain Durand who has given input.

Yanick finished by noting that the team will start on a new analysis 
document to map relevant transition mechanisms to the base scenarios.

Brian Carpenter stated that more progress will be made if it's a working 
group document. Need to think about security boundaries, etc.

Christian Huitema noted his concern that we will have a very unwieldy 
document because things are combinatorial. Margaret noted that the team is 
trying to simplify.

Alain Durand noted that it's a framework, and that it doesn't have to 
cover all cases.

Bob Hinden commented that we're doing scenarios to flesh out 
transition mechanisms, and don't have to have all possible scenarios.

Margaret asked for hands on supporting this document as a wg draft. There 
was unanimous support to accept this as WG document.


===

Second Session:  Wednesday, July 16, 2003 at 1530-1730

======================================================
v6-on-by-default -  Alain Durand

<http://www.ietf.org/internet-drafts/dr
aft-roy-v6ops-v6onbydefault-01.txt>

SLIDES:

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/IPv6ONbyDefault.pdf>

Alain Durand presented the draft on actual experiments of IPv6 on by 
default work at Sun (see draft and slides above).
  we come from a world where breaking existing technology (v4) when
  introducing new technology (v6) is not something we like

  partial ipv6 deployment in our network
  6to4 based, no relay router, no isatap
  some subnets are v6 enabled, some not
  some v4 subnets use private address
  some access to the enterprise network are through ipv4-only VPNs
  v6 addr are published into internal dns

methodology
  took 3 well-known implementations with ipv6 turned on
  observe interesting characteristics in bad v6 connectivity, private 
address, and stuff
  "telnet bigserver"
  measure time it took to fall back from one address to the other

  extremely high delay on one of the 3 implementation

  "when you don't have a router, assume destination is onlink"

  tcp soft-error

  conclusions
    "no RA" case should be "zero delay" -> "onlink" assumption
    tcp timeout assumptions
        use v6-aware vpn, if not: tcp timeout delays
        v6 packet may go to unexpected path (non-vpn side)

  deployment BCP

Rob Austein noted that TCP for v6 was a mess - no difference between v4 and 
v6

Itojun noted that "no RA" case -> ambiguous about outgoing interface, ND 
spec need clarification

Erik Nordmark noted that the onlink rule is useful when RA prefix is 
expired but address is not expired.

Pekka stated that need to analyze pros and cons.

In cases of incomplete v6 connectivity, VERY long delays on some 
implementations (in one case, 225 seconds before route change, even with 
ICMP and RA) ? and this is per-address-tried!?! No reason it should even be 
25 seconds ? need to tweak the spec so timeout is almost zero.

Use AAAA in your DNS with caution!

Use v6-aware VPN, if not (1) TCP timeouts, (2) packets don't go where you 
think, (3) VPN should intercept/sink v6 packets.

Other issues are less critical, but please read draft.

Rob Austein noted that this is good work; we definitely need to write this 
down. Most of these failures were also encountered in v4. We're more 
likely to have lots of addresses in v6, so the problem is worse in v6.

Itojun commented that the ND specification assumes every destination is on 
link, but is not clear when it is not the case. This part of the spec 
could be clarified.

Mohsen Souiss noted that every TCP-based application does not work the same 
way. For example, some web browsers are stuck on IPv6 addresses and this is a 
bad thing. Alain Durand replied that Telnet actually is using the API the 
way it should be used.

Mohsen noted that with dig, for example, we get stuck as well. Some 
application should be.

Pekka Savola noted that it is clear that the application should not be 
fixed first

Alain: commented that issue 1 related to RFC2461 really hurts and should be 
fixed. The fix is necessary to ship product.



Margaret asked if the wg should take this on as a WG item. There was 
unanimous support for this.
Moreover, Margaret, as co-chair of the ipv6 WG, thinks this will result in 
revisiting RFC2461.


===
threedegrees - Christian Huitema
<http://threedegrees.com/>

NO SLIDES

Christian Huitema presented an update on the Threedegrees work he has 
previously presented last year in v6ops.
Main issue is that there are DNS issues in the Threedegrees 
deployment. Some DNS responders respond with very bad responses, but these 
vendors have been contacted and fixes are coming.

The DNS issue has been documented for the dnsop WG, in 
draft-morishi
ta-dnsop-misbehavior-against-aaaa-00.txt.

===
Security - discussion of what we should be doing - Chairs

<http://www.ietf.org/internet-drafts/dr
aft-savola-v6ops-security-overview-00.txt>

SLIDES:

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/v6ops-security.pdf>

Pekka Savola presented his security overview draft (see draft and slides 
above) to facilitate a discussion on what v6ops should be doing on 
security. This discussion was scheduled as security is a core part of the 
charter of v6ops, and there is a need to decide what to do to address this 
issue.

Overview
Look at different kinds of issues
  IPv6 protocol
  Transition mechanisms in general
  Deployment
  + general observations

What should we do about it?
  Very prominent in the charter, something needs to be done
  An abstract approach
  Which drafts would be applicable/which work should be initiated
  Adopt some drafts / initiate some new work?

Different kinds of issues (the IPv6 protocol suite)
  Protocol itself (some generic, some more specific)
    Some people afraid of increased end-to-end transparency
        people used to the NAT "security model"
        education required; need a mechanism to control access

    Some people afraid of increased end-to-end encryption
      people used to the perimeter firewall "security model"
      due to key mgmt difficulties, may not be a huge problem
      highlights the need for end-host, distributed, managed 
firewalling

    Issues in specifications
      how hosts should parse Routing Headers
      how privacy addresses' applicability is not clear
      how ICMPv6 messages may be generated in response to multicast 
packets
      how neighbor discovery "on-link" sending model causes 
complications
      etc.

Different kinds of issues (transition)
  Transition/Co-existence tools
    Tunneling in general
      UDP tunneling typically punches through NATs *AND* firewalls; 
breaking assumptions
      configured IPv6-in-IPv4 tunneling slightly better (typically 
explicit allow/disallow)

    Automatic tunneling mechanisms
      the risks of packet forgery and DoS attacks increase
      the virtual topologies, especially ad-hoc ones, make the network 
architecture more complex

    Relay issues
      communication with third parties in automatic tunneling
      unless carefully done, increases the risk of DoS etc.

Different kinds of issues (deployment)
  Issues in deployment
    Problems with IPv4/6 dual stack use
      certain cases of deployment may incur large timeouts (as 
presented)
      quality of IPv6 routing globally is inferior to IPv4: worse 
quality
      some applications don't handle all the fallbacks properly
      some DNS servers/load-balancers abuse AAAA-querying resolvers

    Insecure service piloting
      testing services/applications without proper access controls

    Operational factors in network infrastructure
      unstable(r) router software, causing virtual topologies or breaks for 
"production" v4
      slower processing (non-line-speed), causing hacks like MPLS
      missing features (e.g. no ability to turn off IPv6 telnet access)
      insecure default configuration/assumptions (if IPv4 access is 
restricted, IPv6 may be allowed by
      default unless explicitly disallowed)
      costs of running one protocol (multiple topologies) vs two 
protocols (double the processing)

Different kinds of issues
  Things to note in general
    Prefer native IPv4/IPv6
      security issues greatly simplified

    Accept configured tunneling
      plain and simple
      where necessary, try to avoid if possible
      explicit knowledge of the end-points: a lot fewer risks

    Avoid automatic tunneling
      security properties typically difficult to handle
      usually bring on a lot of complexity
      may be difficult to retire ("sunset strategy")

What should we do about security?
  Charter lists a lot of items of IPv4/IPv6 operations
    1. solicit input on sec issues from operators/community
    2. provide feedback to IPv6 WG on specs which are likely
        to cause sec issues
    (no 3.)
    4. publish docs on security risks of the operations (w/ sec area)
    5. identify sec issues in deployment scenarios/solutions

  So..
    We had better DO something!
    Security is about the most important item on our charter

  But what to do?
    Good question!
    Feedback sought..

What should we do about security (generic)?
  We need more security expertise
    To evaluate security aspects of the proposals from the first
    And to help in figuring out an answer to the all of below
  We need better idea how to evaluate security
    How to deal with issues transparency etc. imply?
      specify local access control mechanisms?
      try to see if there's work on end-host firewalling?
    How to deal with issues NAT/firewall traversal imply?
      do we need to do more than what other NAT traversal mechanisms have 
done (=nothing)?
      probably yes, but what?
    How to deal with the evaluation of transition mechanisms?
      how much complexity is "too much"?
      how much security is "enough"?

What should we do about security (concrete)?
  Current drafts which could be applicable to this WG
    
draft-dupont-ipv6-rfc3041harmful-02.txt
    
draft-savola-ipv6-rh-ha-security-03.txt
    draft-savola-ipv6-rh-hosts-00.txt
    
draft-cmetz-v6ops-v4mapped-api-harmful-00.txt +
    
draft-itojun-v6ops-v4mapped-harmful-01.txt
    
draft-bellovin-ipv6-accessprefix-01.txt +
    
draft-zill-ipv6wg-zone-prefixlen-00.txt
      something like this is very much in scope
    
draft-savola-v6ops-6to4-security-02.txt
    draft-savola-v6ops-firewalling-01.txt
    
draft-savola-v6ops-security-overview-00.txt
    
draft-okazaki-v6ops-natpt-security-00.txt

  Adopt some of the previous drafts?
    Good candidates
      
draft-savola-v6ops-6to4-security-02.txt
      
draft-savola-v6ops-firewalling-01.txt

    If not adapt, push for being worked on (security area? IPv6 wg?)
      
draft-bellovin-ipv6-accessprefix-01.txt or 
draft-zill-ipv6wg-zone-prefixlen-00.txt

    Should we start working on something new?
      Bring in that security input from the ops/users community!
      How to go about those issues in IPv6 specs?
      Need to create two documents on security? *ARE* there issues to
      document?
        (ch4): potential security risks in the operation of 
IPv4/IPv6?
        (ch6): identify open sec issues with deployment scenarios?
      If so, maybe need a small editorial team (or DT).

There seemed to be a number of security people in the room for the 
discuss that follows.

Discussion:

Itojun: Agreed with overall direction of this document. 6to4 relay is his 
hot issue, and he is still interested in getting his document 
published.

Rob Austein: tried to work on these issues at IAB workshop last year ? 
could dig this up again. Pekka and I are converging offline, on a 
semi-configured tunnel that's easier to use than existing proposals.

Margaret: How do we get "significant study"? IRTF research group?

Rob: talk to Bellovin.

Christian Huitema: analysis should take place. Lots of proposals to limit 
impact of "automatic tunneling".  You exaggerate the danger of 6to4 
relays. Source spoofing attacks happen today, other dangers are worse.

Randy Bush: security threats are best addressed by updating an existing 
document. Randy noted that he disagreed with Christian.

Erik Nordmark: the WG is supposed to be looking at 6to4 security. 
Operators can look at the document and assess risks.

Pekka: Not significantly worse than the v4 Internet today.

Alain: Pekka's 6to4 document is already good. Make it a WG item and 
last-call it, move forward.

Brian Carpenter: Pekka did a good job. Don't think there's much we can 
change in 6to4 without abolishing it.

Margaret: Enough recent readers to make decision on making Pekka's draft a WG 
item?

Randy: it's an analysis of a WG protocol ? how much debate do we need?

There was a unanimous show of hands to accept Pekka's draft as s WG 
document.

Gregory (security product vendor): We've been talking about NAT 
security a lot at my company. The world believes this, no matter whether we 
believe it or not. NAT default is nothing flows, v6 default is 
everything flows. Are we building walls or roads here?

Someone asked how hard is it to establish inside-to-outside 
initiation as a default? Any vendor can do this today.

Margaret: "How difficult could it be" for someone configuring routers in 
their home? Impossible. Can vendors pre-configure all of this?

Bob Hinden: not hard to start firewall with restrictive set of rules.

Tony Hain: we're talking about security, and NAT doesn't equal 
security. If you're going to replace a filtering device, you probably want to 
replace it with another filtering device.

Gregory: Stateful inspection is hardest at application gateway level, 
especially with dynamic ports. Can we define this, or make 
application guys define this (via registry)? Then Mom could do this 
one-click?

Margaret: this is more than we can do here.

Christian: this is v6ops, not NATops. What we have to preserve is the 
security of the users, and there are many ways to accomplish this (host 
firewalls, etc.).

Matt: how to move forward? Divide-and-conquer with small documents doing 
threat analysis? Don't do an 80-page document!

Alain Durand: one thing we've observed is that we need to make sure v4 and v6 
security policy provide the same security. We need tools to make sure two 
policies match, including update frequency.

Rob Austein: two ways to protect Mom. Mom outsources this to an ISP, or UI on 
the box that Mom buys. This is a challenge for UI and application behind UI, 
and needs to be updated whenever a new application comes out.

Gregory: what we need to preserve is NATish isolation, not NAT itself.

Magaret: ADs should say how to figure out this issue.

===
NAT-PT Applicability Statement team report - Peter Barany
<no draft yet>

SLIDES

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/NAT-PT-applicability.pdf>

<http://6bone.net/v6ops/minutes/IETF-57
-Vienna/NAT-PT-applicability.ppt>

Peter Barany presented a report from the new NAT-PT Applicability 
Statement team:

Background
At the IETF V6OPS WG meeting in San Francisco, CA (IETF #56 meeting)
  Discussion took place about status of standards track RFCs 
NAT-PT/SIIT (2766/2765) (just sitting at PS)
  No active editor for NAT-PT
  Need to decide what to do by March 03 with NAT-PT/SIIT
    Deprecate?
    Update?
    Write an Applicability Statement?
  Decision: Write an Applicability Statement
    Form a Design Team

Design Team Members
  Suresh Satapati (Design Team Lead)
  Rob Austein
  Peter Barany
  Karim El-Malki
  Satomi Okazaki
  Sentil Sivakumar
  Hao Wang

Deliverables
  NAT-PT Applicability Statement

No Internet draft available yet.

Scope & Goals

  Document the applicability (or non-applicability) of NAT-PT
    See RFC 2026 for definition of Applicability Statement
  Proposing modifications to NAT-PT (RFC 2766) (or extensions to make 
NAT-PT applicable)
    is not within the scope of the Design Team

Outline
"Table of Contents
 1. Introduction
 2. Applicability
  2.1 Deployment Scenarios
  2.2 Limitations
 3. Security Considerations
 4. References
 5. Authors and Contact Information
 6. Full Copyright Statement

For 2.1 - Deployment scenarios agreed upon by Design Team
  2.1.1 3GPP Networks
  2.1.2 Futuristic Scenario
    Entire network infrastructure is IPv6 but there are some existing IPv6 
hosts (or applications) that cannot be upgraded

  FFS
    3GPP2 Networks

For 2.2 - Limitations
  Some ideas
    Applications with IP addresses embedded in payload
    Address selection
    End-to-end security
      IPsec, DNSSEC
    Multicast
    Mobility
    Single point of failure


Question about SIIT: do we want to also include SIIT? Should it be 
considered, as well as NAT-PT? Same question with 
bump-in-the-stack (BIS).

Margaret: OK to work on theses RFCs as well.

The Design Team has a mandate to include SIIT (RFC 2765) in the NAT-PT 
Applicability Statement document (not sure whether or not we have to 
change the title of the document to reflect this). Where SIIT is 
referenced by RFCs/I-Ds other than NAT-PT (e.g., RFC 2767 BIS), a 
separate section should/can be included in the NAT-PT 
Applicability Statement document discussing SIIT in this context.
Christian: you listed NAT-PT scenarios, but we found scenarios where 
NAT-PT should NOT be deployed ? these should be included as well. 
Applicability statements can be negative ? "don't use this here".

Marc Blanchet: think about ICMP! Troubleshooting or something, but it's an 
important topic.

Alain: SIIT depends on where translation is happening. Pekka: some 
confusion about what "ICMP" really is ? SIIT is not usually used on its 
own.

Rob Austein ? Most of the experience we have with SIIT was from NAT-PT. I 
wish I could forget ICMP.

Peter Barany remarked that this would be handled/discussed most likely in 
the SIIT portion of the NAT-PT Applicability Statement document (as it 
relates to NAT-PT ... not BIS). ICMPv6 translation is discussed in detail in 
RFC 2765 (also, some of this will necessarily spill over into 
mobility/MIPv6 discussed since MIPv6 uses extensions to ICMPv6 ... as do 
other IPv6 technologies, e.g., multicast). We need to think about how to 
partition the document to handle ICMPv6 and SIIT.

It was also noted that the Design Team should think about using the 
Cellular Networks, Unmanaged Networks, ISP Networks, and Enterprise 
Networks as possible scenario sub-sections in the NAT-PT 
Applicability Statement document since these scenarios are already being 
addressed in separate I-Ds by the appropriate Design Teams and the work on 
NAT-PT could be re-used from those 4 Design Teams. Peter said that the 
design team will look at this.

Margaret: agreement of the WG to make this work a WG item will be taken on 
the list when the first draft is available.

===
Writing IPv6 Applications report - Myung-ki Shin & Pekka Savola

<http://www.ietf.org/internet-drafts/dr
aft-shin-v6ops-application-transition-01.txt>

SLIDES:

<http://6bone.net/v6ops/minutes/IETF-57-Vienna/apps.pdf>

<http://6bone.net/v6ops/minutes/IETF-57-Vienna/apps.ppt>

Myung-ki Shin presented the newest version of his application 
transition draft (see draft and slides above).

Why this draft:
  As IPv6 is deployed, the application developers and the 
administrators will face several problems
    clarifies the problems and considerations
    application transition scenarios (cases)
    proposes guidelines on developing IP version-independent 
applications
  One of the charter items of this wg
    good starting point for this topic

General Problems with IPv6 application transition
  Dual-stack vs. application versions
    Operating system being dual stack does not mean having both IPv4 and 
IPv6 applications
  DNS name resolution
    A client application can not know the version of peer 
application by only doing a DNS name lookup
  Application selection
    Users may be confused by their various application versions 
(IPv4-only, IPv6-only, IPv4/IPv6) because they don't know the version of 
peer application by DNS query results

Application porting considerations
"IP version dependencies in applications
  Presentation format for an IP address
    dotted-decimal string for IPv4 vs. hexadecimal string for IPv6
  Transport layer API
    functions to establish communications and to exchange 
information
  Name and address resolution
    conversion functions b/w hostnames and IP addresses
  Specific IP dependencies
    IP address selection, application framing, storage of IP addresses

Developing IP version-independent applications
  In order to allow applications to communicate with other IPv6 nodes, the 
first priority is to convert the applications supporting both IPv4 and IPv6
    IP version-independent structures & APIs
  The applications should do iterated jobs for finding the working 
address out of addresses returned by getaddrinfo()
  The applications will have to work properly in IPv4-only nodes 
(whether IPv6 protocol is completely disabled)

Open Issues
  Transition mechanism considerations
    Handling NAT-PT(DNS-ALG) address prefix
    Any other mechanisms ?
  Security considerations
    Handling IPv4 mapped IPv6-addresses

Applications Area persons will join this team (as of Open Apps Area 
meeting on Monday).

Margaret: GRID people want to contribute, too.

Dual-stack doesn't mean clients have both v4 and v6 applications.

DNS does not know the version of an application based on DNS lookup.

Looking at v4 applications in dual-stack, then v6 applications in 
dual-stack.

Dual-stack applications on v4-only host ? EPROTONOSUPPORT or 
EAPNOSUPPORT errors dump out of the socket loop, and v4 is never tried!

Presentation format, transport API, naming and addressing...

Several guidelines on developing IP version-independent 
applications, including running in v4-only nodes.

Security considerations ? v4-mapped v6 addresses.

Pekka: comments from Apps AD ? address being overloaded as identifier ? 
needs to be clarified in this document.

Q: failure of v6 address and fall-back to v4? Preference based on 
performance, not just being v6? Alain: this is no different from 
dual-homing case.

Q: with default address selection, we could override v6 preference choice to 
v4.

Brian: is this going to be a generic I/O system? Brian is almost-WG chair in 
Global GRID forum. Need to figure out how to work together.

Q: v6-only? If you use v6 APIs, you have access to v4 addresses in v6 
format?

Christian: one may want to develop v6 only app because of NAT 
traversal issue.

Alain: don't want to ship one app for each case.

Patrik: What do you mean by "application"? "GETHOSTBYNAME" is all I want to 
do (multiple interfaces, etc. are things I'd like to ignore)... 
Discussion is strange...

Margaret: you're saying document deals with useful issues, but how many are 
applicable to applications writers?

Q: Are C libraries the kind of applications we're talking about? Connect 
serially or in parallel? Margaret: DNS is an application, and TCP is on the 
hairy edge of being an application.

The document will be revised with the help of applications people, and will 
come back to v6ops later.

===
Status report of IPv4 Survey drafts - Chairs

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-ipv4survey-intro-01.txt>

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-ipv4survey-apps-01.txt>

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-ipv4survey-ops-01.txt>

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-ipv4survey-int-01.txt>

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-ipv4survey-routing-01.txt>

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-ipv4survey-sec-01.txt>

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-ipv4survey-subip-01.txt>

<http://www.ietf.org/internet-drafts/dr
aft-ietf-v6ops-ipv4survey-trans-01.txt>

SLIDES: none

Pekka gave a status report of the progress of the IPv4 Survey 
individual drafts since the last IETF (see drafts above).

Pekka said that he and Margaret had pinged the appropriate ADs since 
IETF-56, and got responses from about four areas, and also met with the 
APPS area at this meeting. The nine documents now have individual 
editors assigned to each.

Documents will be updated after the first round of comments received from 
the areas. The co-chairs will follow up with other areas not yet heard 
from.

Pekka noted that these documents need to be credible ? so all wg 
participants are requested to review them!

There were no comments.

===
Meeting adjourned.

-end