Atlanta V6Ops Meeting Minutes

[sar@epilogue.com]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi all,

Here are the meeting minutes for the Atlanta meeting.
I'm planning to submit them on friday.  If you have any
issues with them please send mail.

regards,
sar

**************************************

			IPv6 Operations WG
			IETF55 Atlanta
			November 20 2002

Chairs: Jun-ichiro "Itojun" Hagino <itojun@iijlab.net>
	Margaret Wasserman and <mrw@windriver.com>

Notes: Shawn A. Routhier <sar@epilogue.com>

As with most meetings this one started off with some agenda bashing
and a brief description of the previous and current status.  For this
WG this included a description of an interim meeting and the current
work items.

The interim meeting was held to launch the new WG and to discuss the
charter and goals of the new WG.  The initial work items accepted by
the WG include: transition mechanisms, the survey of IPv4 addresses
within RFCs and the 3GPP and unmanaged scenarios.  New work items can
be accepted by the WG but will need to go through the standard WG
process.

*

We then proceeded to status reports and discussions on the four
deployment scenarios that are currently under investigation.  These
include: unmanaged networks, ISPs, enterprises and cellular networks.

*

Christian Huitema - Unmanaged Networks Team
Team members: R. Austein, S. Satapati, C. Huitema, R. van der Pol
draft-ietf-ngtrans-unmanscope-02.txt
draft-huitema-ngtrans-unmaneval-01.txt

This group held a productive interim meeting and has above two drafts
that have not been renamed into the V6OPS WG.

The scenarios document needs some final clean up and minor edits but
they belive the draft is mostly complete with two open issues dealing
with the privacy and interoperability requirements.

The privacy issue deals with the amount of privacy supplied by the transition
mechanisms.  Christian presented two opinions.  Opinion 1 insists that there
should not be any "privacy regression" - that is people using IPv6 should have
no less privacy than people using IPv4 and a NAT.  Opinion 2 is that the
current level of privacy is just a random by-product of using a NAT and as
such should not be turned into a requirement.  This opinion also holds that
other items, such as cookies, will break privacy.

The floor was then opened to the WG for discussion on this topic.

The sense of the room seemed to be that the options should be listed
without being made requirements.  Points from the discussion included
1) NATs with dynamic addresses could be added as a more private option.
2) The privacy requirements are not independent of the application.  Different
applications may choose different tradeoffs and attempting to choose a single
option for the entire network might not work.
3) This is not simply a technical area.  The social and legal realms may
have implications for this area.  As those realms are also evolving trying
to codify them might not be useful.
4) The question of making the tradeoff was raised - who makes it, as well
as when and how.  
5) There is a difference between using a different address frequently
(changing your address) and simply using an address that isn't derived
directly from your MAC address.

The final point of discussion was how this information should be presented or
in what draft it should be included.  The options are (1) try and put all of
the privacy issues into a single document or (2) have each of the documents
include a description of their issues.  The WG seems to like (2) more with
the caveat that eventually we may move to having a single document - either
one of the current ones or a separate one - that handles the specific privacy
issues and concerns.
	
The interoperability issue deals with how much IPv4 <-> IPv6 interoperability
is required during the IPv4 to IPv6 transition.  We could aim for either only
local interoperability or for full compatibility.  There seems to be some
consensus that local compatibility is required.

The questions seem to be whether an IPv4 node should be able to reach services
supplied by an IPv6 node or if an IPv6 node should be able to reach an IPv4
node.  The WG seemed to feel that the number of IPv6 only devices would be low
enough that we needn't worry about them that much.  However there was
resistance to this point with comments about IPv6 only devices and devices
with dual stacks that are not configured to use the IPv4 side of the stack.
It was also pointed out that an answer to these questions would depend on the
cost of the options as well as which end is which and what each node is 
trying to do (be a host or server etc).

Christian then discussed the solutions document which is currently a work in
progress.  It includes four cases.  

The first case (A) was that of a dual stack node behind a NAT with an IPv4
only ISP.  The document suggests using Teredo in this case, but there was no
clear consensus in the meeting that we need or should try to solve this
problem.  There was also some discussion about whether Teredo might be an
overly complicated solution that would not be deployed in the real world.
This discussion was sent to the mailing list.

The second case (B) was that of a dual stack router and ISP.
The discussion for this case covered NAT-PT and there was good consensus
that we need a better NAT-PT specification.  Three specific points were: the
need for a reserved mapping prefix in IPv6, the need for a reserved mapping
for IPv6 to IPv4 addresses and the dropping of automatic translation within
the DNS.

The reserved mapping from IPv6 to IPv4 addresses would make it easier for an
entity to determine that it was communicating with an IPv6 entity and should
attempt to use a native IPv6 address.  

Dropping the automatic translation would allow dual stack nodes to make their
own decision about which address to use.

The discussion brought up two points.  The first was to suggest that IPv6 only
hosts shouldn't talk to IPv4 only hosts, if a node wishes to be able to talk
to an IPv4 only host it should be dual stacked.  The second was that the
solutions were becoming too complex.

The third case (C) was that of a dual stack gateway and a single stack
ISP which was using IPv4.  In this case the document suggests using 6to4.

The fourth case (D) was that of a dual stack gateway and a single stack ISP
which was using IPv6.

The recommendations from Christian were as follow.
The scenarios document is mostly read and should be sent along for WG review,
The solutions document still needs some work and is not ready for review,
however either it or some of the problems it describes should be accepted by
the WG for further work.

*

Cleveland Mickles - ISP Team
draft-mickles-v6ops-isp-cases-02.txt

This group has been working on the scenarios document and had planned to have
it updated prior to IETF55, however they didn't met that deadline.  Several
sections have been added and some sections reworked however several sections
require more work.  These sections include: internet exchange point,
broadband Ethernet and infrastructure.  They plan to submit another revision
of the document by the end of the year and then to start work on the solutions
document.

One set of comments they received dealt with having too much information in
some sections.  They attempted to rectify this, but the consensus of those
that had read the draft was that there was still too much detail.

They had also received some comments that the draft should address
multi-homing.  In the meeting there was one comment that multi-homing is
important but there were several voices against its inclusion.

There was a suggestion that they should include a small amount of text or
a pointer to text describing possible show stoppers.

The decision was to wait until the draft is produced and the WG can examine
it then decide if it should be adopted by the WG.

*

Yanick Pouffary - Enterprise Team
draft-pouffary-v6ops-ent-v6net-01.txt

This is a fairly new group and so the drat is not yet complete.  In this
document the design group attempts to specify the scope of the document and
the goals and non-goals.  One of the primary goals was to identify and provide
guidelines and tools for the transition.  The following covers some of the
points Yanick made in her presentation, for all the points please see the
slides.

The document includes a definition of "enterprise".  The group felt that this
description needs more context.

The design group assumes that the reasons and methods for adoption of IPv6
will vary across users.  They attempt to specify some of the variables that
will influence how the transition will occur in some cases these will be
external business reasons.

The draft defines six scenarios.  These are not intended to cover all possible
options but are intended to include most of the general ones.  The WG is
requested to contribute any major scenarios they feel are missing.

The design group feels that enterprises will need to do an inventory and 
determine what software will be affected by the transition.  The enterprise
will also need to determine what software can be extended and what will need
to be updated.

There were several comments about getting more deployment experience - some
of this is already in the document as several members of the design team are
deployers.  One suggestion was for producing two sets of documents.  One
would be a distilled consensus document.  The other set would describe what
various groups have already done and what problems and pitfalls they have
encountered.  A further suggestion was that getting reports from non-vendors
would be especially useful and that it might be useful to get similar reports
for the other classes (ISP, Cellular etc).  While the meeting didn't decide
to create a separate set of documents the chair requested deployment reports
from anybody who has such experience.

There was a comment that the draft had two many acronyms, which the meeting
agreed with.  There was also some questions about the layout of the draft.

Finally the design group plans to put the solutions into a separate document.

*

Jonne Soininen Cellular Networks Team
draft-ietf-v6ops-3gpp-cases-00.txt
draft-wiljakka-3gpp-ipv6-transition-02.txt

Jonne pointed out that this group started first and so is somewhat ahead of the
other groups.  

The scenarios document is already a WG document.  This document seems to be
stable and does not require major changes, though there are a few editorial
tweaks to be handled.  There was a request for a dual stack IMS scenario which
was deemed out of scope for the design group.

The last set of changes to the analysis document were mostly editorial and
there are still several items left to do.  These include clarifying the use
of static vs dynamic tunneling, documenting the NAT-PT vs NAT64 issues,
removing an error in the IMS 1 scenario and changing the name of the document
(to analysis document).  They also plan to use the Thakur document as input
for the analysis document but need to check with the authors first. Jonne also
described the scenarios they have developed for the analysis document so far
these are.  Please see the document for a description of these scenarios.

The small number of people that have read the scenarios document feel that
it is stable and acceptable for it to go to last call.  There didn't seem to
be a large amount of interest in the analysis document but it has been
accepted as a working group item.  The design group is to be turned into
an authors group.

One of the major areas of discussion was NAT-PT.  The group agrees that there
are substantial problems with NAT-PT however it is unclear as to how we can
proceed given our current charter.  (Note: Alain Durand has written a,
possibly expired, draft on some of the issues.)  Some of the points made in
the discussion are:
1) NAT can not be a general solution - it may work for some applications but
other applications will need a more specific ALG.
2) NAT-PT may eventually disappear while NATv4 may be around for a while.  If
so we may need to rework NAT-PT to make it as good as, but no better than
NATv4.
3) Perhaps we should get some operational experience about the tools we have
to determine they are truly broken before we try to write yet another.
4) The major scenario in which IPv6 only needs to inter-operate with IPv4 only
may be the end game.  When we want to allow for the use of legacy systems
and most of the net is IPv6 only.
5) Some functions, such as DNS, will need to be dual stacked and we may need
to understand how they interact with IPv6 before we can go to IPv6 only.
6) George Tsirtsis, the author of the RFC, pointed out that NAT-PT
was not meant as a general solution.  As such one of the first steps in
updating the document should be to determine in which cases NAT-PT is useful.
7) One of the scenarios in the cellular document may require NAT-PT.

One of the ADs, Thomas Narten, stated that if NAT-PT is broken then it should
either be fixed or tossed.

There were several suggestions as to what we should do including that NAT-PT
should be revised or at least have an applicability statement inserted.
There is no consensus that it can be fixed especially for all things that might
want to use it.

The meeting agreed that we should ask the ADs to add updating NAT-PT to our
charter.

*

The following item describes the status and open issues of one of the
current work items.

*

Erik Nordmark - draft-ietf-ngtrans-mech-v2-01.txt (update to RFC2893)

Erik raised several issues and there was a small amount of discussion on some
of them, however most of the discussion has been directed to the mailing list.
Erik will send a draft to the mailing list with a basic plan of updating the
draft according to the edits that the WG can agree on.

The following list describes the issues that Erik raised.

Should we drop mentions of unidirectional tunnels? (No discussion.)

Is 1280 a reasonable MTU for encapsulators without dynamic tunnel MTU
discovery?
In the discussion it appears that a slightly larger size would be useful for
mobile IP - this size would be 1280 plus space for another header.

Is 4400 a reasonable cap on dynamic tunnel MTU discovery?  
In the discussion it was pointed out that it doesn't seem necessary to have a
limit unless decpsulators have a large physical interface MTU, however most
discussion should occur on the mailing list.

Any other concerns about reassembly buffer size? (No discussion.)

The IPv4 native address group includes IPv4 mapped addresses as currently
defined.  Is this an issue that needs to be dealt with?  (No discussion.)

Any comments on ingress filtering?

*

The following two items are proposals for new work items.

*

Myung-Ki Shin - draft-shin-v6ops-application-transition-00.txt

This is an attempt to give developers some guidelines when writing or
modifying applications.

The discussion was quite short.  One point was that some of the assumptions
may be incorrect for example some applications can't be dual stacked.  Another
point was that an effort such as this should get a broader view.  There is an
effort underway to move this into the application area where it can get the
appropriate review.  This effort has been ongoing and unsuccessful so far but
may be working better now.

The chairs are to talk to the ADs to determine how to move forward on this
effort.

*

Pekka Savola - draft-savola-v6ops-6to4-security-00.txt

The basic issue is that the 6to4 specification is terse on security
considerations and that security checks can be difficult to implement if
multiple automatic tunneling mechanisms are used in the same box.

One specific issue that Pekka brought up was that of 6to4 relay spoofing, in
which an attacker could pretend to be a relay and send packets to a 6to4
router.  He supplied two possible patches: (1) relays should always use
192.88.99.0/24 (from rfc3068) as their source address and (2) limited
distribution of more specific 6to4 routes.  

The discussion questioned if (1) would be effective and indicated that some
sort of cryptographic relationship would be necessary.  Christian Huitema
mentioned that this was being investigated as part of Teredo and that they
are considering some sort of three way handshake.  However this is a DDOS
problem and it may not be unsolvable.  There was some other discussion which
included the following points: the use of asymmetric routing may be a flaw in
the model, the lack of capability of ingress routing is part of the problem,
better tracing in ICMP would help and finally that the problem is difficult
but could be solved.  

As the WG was running out of time this discussion was ended and moved to the
mailing list.

**

We finished with some comments by Harald Alvestrand about the transition
from the IPNG WG to the V6OPS WG.  Harald has also sent a note describing this
transition to the mailing list, people interested in this issue should also
consult that note.

Over the summer the ADs responsible for IPv4 became concerned about the
NGtrans effort.  They were concerned that there was a growing complexity in
the transition options that would present deployment difficulties.  This led
to discussions about re-chartering the WG with several options being discussed
including re-chartering the WG and concluding the current WG and creating a
new WG.  The end result of these discussions was to charter a new group and
close the old group.  The new group starts with a narrow charter that may be
expanded as necessary.

Harald pointed out that while this narrow charter is designed to focus this
particular work effort, it is not meant to stop other work.  People who are
interested in items that are not included in the charter of the WG are
encouraged to work on them with the standard options available.  These options
include bringing the item back to the WG or IESG after more work to try and
get it adopted by the WG, publishing it as Informational or Experimental
within the IETF framework or possibly taking the work somewhere else.

There was a brief (as we were already past time) discussion of this issue that
became a discussion of general IESG/IETF issues. Two of these issues were the
requirements for publication of a document and for allocation of a resource.
Both of these are handled on a cases by case basis but there are some general
rules.  In the case of publishing a document the requirements are higher for
those on the standards track than those that will are Informational or
Experimental.  In the case of resource allocation, such as protocol numbers,
the requirements are based on the scarcity of the resources.  For scarce
resources, such as protocol numbers, a stable standards track document is
required, less scarce resources may be allocated in an Experimental document
or via IANA.  (Editor's note: there was also some discussion about resource
allocation at the Thursday night plenary.)  

Two possible problems with the current process were also mentioned.  The first
is that it is possible for and AD to stall documents and the second is that it
is difficult for a WG to indicate that they believe an AD has erred.

In conclusion Harald reminded the group that he (or the IESG if appropriate)
needs to hear about things in order to try and fix any problems and he
encouraged people to talk to him (or them) if you believe there is some
sort of process problem.