Subject: (ngtrans) final ngtrans agenda for IETF-53 in Minneapolis

From: Bob Fink <[email-masked]>
Date: Mon, 11 Mar 2002 16:13:02 -0800

NGtrans Folk,

Below is the final agenda for the Minneapolis ngtrans meeting based on 
discussions with our AD on the importance of making progress on a new 
direction within the ngtrans working group. Thus we will be focusing the 
first hour on issues and discussion towards developing a Transition 
Architecture, the next 30 minutes on critical ongoing project work, and the 
last 30 minutes on new project proposals.

We apologize in advance for any inconvenience this reshuffling of times may 
cause; we believe that it is important at this time to advance to the most 
important work of ngtrans, which is identifying a Transition Architecture.

Due to the limited time available, especially for critical ongoing work and 
new project proposals, the chairs will be sticking to the times allotted 
very strictly. Also, at this time more no new project presentations will be 
accepted for this meeting. Critical ongoing work will be added only if 
there are clearly defined issues under discussion on the list requiring 
meeting time.

Currently ngtrans is scheduled for:

   MONDAY, March 18, 2002
   1530-1730 Afternoon Sessions II
   OPS     ngtrans  Next Generation Transition WG

Note that with so many new projects up for discussion, and our pending new 
charter and directions, the authors will need to make a strong case for 
approval in the time available. Whatever the sentiment for a new project, 
it will be taken to the list after the meeting for further discussion with 
the chairs then making the final call along with help from our AD as 
necessary.

Finally, note that we have removed the 6bone pTLA discussion in interest of 
time. Bob Fink will be scheduling a lunch time 6bone meeting for this topic.

Thanks,

Bob, Alain and Tony

=====================================
Welcome - Bob Fink

Agenda Bashing - Bob Fink

=====================================
Transition Architecture discussions, led by Tony Hain - 60 mins
<there is no ID as this is a formative discussion and will mostly be
  interactive with the attendees at the meeting>

=====================================
Critical Ongoing Work - 30 mins total
===
ISATAP, Fred Templin - 20 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-03.txt>

---
DSTM, Octavio Medina - 10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-07.txt>

=====================================
New Project Proposals - 30 mins total
===
APPLICATION-TRANSITION, Shin - 5 mins (new project request)
<http://www.ietf.org/internet-drafts/draft-shin-ngtrans-application-transition-01.txt>

---
DSTM-PORTS, Myung-Ki Shin - 5 (new project request)
<http://www.ietf.org/internet-drafts/draft-shin-ngtrans-dstm-ports-00.txt>

---
DSTM-VPN, Laurent Toutain - 5 mins (new project request)
<http://www.ietf.org/internet-drafts/draft-richier-dstm-vpn-00.txt>

---
ND-DSTM, Gerard Gastaud - 5 mins  (new project request)
http://www.ietf.org/internet-drafts/draft-bereski-ngtrans-nd-dstm-01.txt

---
mipv6overmipv4, Changwen Liu - 5 mins (new project request)
<http://www.ietf.org/internet-drafts/draft-liu-mobileip-mipv6overmipv4-00.txt>

---
CONNECT-IPv6-IGP, Gerard Gastaud - 5 mins  (new project request)
<http://www.ietf.org/internet-drafts/draft-many-ngtrans-connect-ipv6-igp-01.txt>

-end

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Mar 2002 01:27:24 +0200 (EET)

> <http://www.ietf.org/internet-drafts/draft-shin-ngtrans-dstm-ports-00.txt>

As noted already on 27th Feb, I think this is an extremely bad idea:  
very large portion of applications use their own port numbers, and this
could not be used in these scenarios: it's really difficult to police 
which ports are used (per protocol) in the node.

I guess the question is whether a generally bad idea can be limited to 
very specific scenarios where it _might_ be sometimes useful: whether this 
is too dangerous (I think so) to be worth it.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 19 Mar 2002 09:44:06 +0900

> is too dangerous (I think so) to be worth it.

   As you said, the ports option is limited to client applications that do not
   insist on choosing their own source port number.
   (We already mentioned in section 8. Applicability Statement.)
   But, (I think) other general applications can use this idea,
   so that a DSTM network administrators can get the benefits
   on reducing the size of the required IPv4 address pool.
   (In a real situation, it might be more important to reduce
    the size of the required IPv4 address pool.)

   This idea will be seperated from main DSTM, and used as an OPTION.
   (This means DSTM nework administrators can choose the option
   according as their situation.) - it depends on DSTM server's operation
policy.
   I believe if a DSTM network administrator do not have a sufficient IPv4
   address pool, using this option can support to establesh new sessions
   for IPv4 communications without waiting or stopping.

   Myung-Ki.

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 18 Mar 2002 20:34:50 -0600

I think that there might be enother problem with the port extensions.
I don't think that IPSec would work with this extensions.  If the
TCP/UDP header is encrypted, the TEP will not be able to cache the
port that it's supposed to do.

Another problem that I have with the document is in the wording ( and
the implied design).  The document states in section 7:
	The DSTM node MUST assign the port range provided by the DSTM
     server to an interface, instead of existing port range, supporting
     the client's IPv4 stack implementation.

Ports are not assigned to the interface.  They are a transport endpoint
identifier and have nothing to do with an interface.

-vlad

---

From: Alain Durand <[email-masked]>
Date: Mon, 18 Mar 2002 20:46:49 -0600

>port that it's supposed to do.

That's a big one...
The whole idea of DSTM is to provide and End to End IPv4 path
to the IPv6 node. If by using the port option you can not use IPsec,
then one can question why you are doing DSTM in the first place.

	- Alain.
--

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 04:13:33 +0100

In your previous mail you wrote:

   That's a big one...
   
=> IMHO the port option is like adding a NAT in DSTM. It saves addresses
but remains an abomination.

Regards

[email-masked]

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 18 Mar 2002 21:24:15 -0600

> but remains an abomination.

Thanks.  You said it better then I could have.

-vlad

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Mar 2002 05:24:15 +0200 (EET)

> but remains an abomination.

IMHO if you really have to save addresses, why don't you just give out 
private IPv4 addresses to the DSTM nodes and do NAT.  Much cleaner 
solution, and nothing to do with IPv6 then!

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 19 Mar 2002 13:09:57 +0900

> port that it's supposed to do.

   In order to solve this problem, we can consider a new destination option
   header carrying the source port number.

   If we use it, the TEP does not require to do lookups the port field
   of the 4over6 packets.

   Myung-Ki.

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 19 Mar 2002 13:18:53 +0900

> solution, and nothing to do with IPv6 then!

  In my opinion,  at least, DSTM+NAT is bad approach.
  As I said, one of DSTM benefits is to provide end-2-end computing for IPv4
without
  translation.

  Myung-Ki.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Mar 2002 06:21:39 +0200 (EET)

>   As I said, one of DSTM benefits is to provide end-2-end computing for IPv4

I'm not sure if that's a goal of DSTM: the goal of DSTM is to be able to 
run IPv6-only network infrastructure with dual-stack nodes.

Sure, getting end-2-end IPv4 is always a plus, but nothing specific to 
DSTM. And there should be some use for IPv6 too ;-)

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 19 Mar 2002 13:45:42 +0900

> DSTM. And there should be some use for IPv6 too ;-)

   No, see the section 3. DSTM Overview and Assumptions in DSTM spec.
   http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-07.txt

   ====
   The core assumption within this mechanism is that it is totally
   transparent to applications, which can continue to work with IPv4
   addresses. It is also transparent to the network, where only IPv6
   packets are carried. It is the authors' viewpoint that the user, in
   this case, has deployed IPv6 to support end to end computing without
   translation.  This aspect is fundamental during a transition process
   to guarantee that every existing application will continue to work
   (e.g. IPsec, H.323), despite the presence of IPv4 addresses in the
   payload of a packet.

   Myung-Ki.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Mar 2002 07:03:41 +0200 (EET)

>    (e.g. IPsec, H.323), despite the presence of IPv4 addresses in the

Ah, missed the last part.

But DSTM ports still does not seem to fulfill that requirement:  some
applications *will* cease to work (or more precisely, probably start to
disrupt the applications of other DSTM nodes).. and then _every existing 
application_ will most definitely not work.

When we break the assumption we have a couple of choices:

 1) revise the assumptions (DSTM draft)
 2) acknowledge that both will break the assumption, but continue 
regardless
  a) by specifying more (dstm-ports)
  b) by letting the user continue as he did before implementing DSTM (do 
nothing)

IMO, 2.b) is obvious: if the site had enough IPv4 addresses to guarantee 
end2end before DSTM, in most cases it has enough IPv4 addresses after 
DSTM too.  On the other hand, if the site didn't have enough IPv4 
addresses, e2e applications were broken _to begin with_, and DSTM causes 
no _additional_ problems.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 16:08:40 +0100

=> oh NO!