Subject: [midcom] RE: Some comments on scenario draft

From: "Christian Huitema" <[email-masked]>
Date: Fri, 11 May 2001 09:58:55 -0700

The plan of record for IPv6 is indeed that you will not use address
translation and IPv6; frankly, if you still used NAT, there would be
little reason to move to IPv6 in the first place! What I point out in
the scenario is, what changes when IPv6 gives you global addressing.

You are right about discovery. The "signaling server" has to understand
the location of the firewalls in order to open the proper holes. This is
not in scope for MIDCOM the scenarios merely assume that discovery
somehow happens, and that the server knows which firewall will be used.
That should definitely work in the main cases, when there is exactly one
firewall per domain, or maybe one firewall cluster.

-- Christian Huitema 

-----Original Message-----
From: Cedric Aoun [mailto:[email-masked]] 
Sent: Friday, May 11, 2001 7:43 AM
To: Christian Huitema; Midcom IETF (E-mail)
Subject: Some comments on scenario draft

Christian, 
I have a couple of minor comments on the draft: 
-I'm not quite sure that basic NAT (1 address to 1 address mapping) will
be completely forgotten in IPv6, enterprises will still would like to
have a certain independence from their ISP since the used addresses are
provided by the ISP and they don't want to change their addresses when
they change their ISP.
-In big corporations we could have a lot of cases where the signaling
flow will traverse a different Middle box than the bearer path, this is
a realistic scenario.
It won't happen for residential customers and SME (might happen) but for
big corporations having several gateways it will happen.
I know that middle box discovery is out of scope of the workgroup, and
that is the main reason why this scenario is not in your draft but I
think it is worth to
note it. 
I'm sure that other people in the list are interested in this scenario
as well. 
Feedback is welcomed 
Regards 
Cedric Aoun 
Nortel Networks 
33, quai Paul Doumer 
Paris La Defense 
92415 Courbevoie Cedex France 
Gsm +33 6 85 74 43 04 
Fax  +33 1 46215598 
[email-masked] 

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 11 May 2001 11:28:47 -0700 (PDT)

> the scenario is, what changes when IPv6 gives you global addressing.

Christian - I do not agree with your assertion above and a similar
comment made in section 2.4. NAT-PT plays an important role in v6
transition strategy. NAT-PT is the only means of communication between 
V6-only hosts and V4-only hosts.

I believe, the intoduction of V6 and V6 transition mechanisms in this 
document is a diversion to the main theme and would not suggest this 
to be part of this document. 6-to-4 router is neither a middlebox nor 
a MIDCOM agent nor an application we are trying to facilitate using the 
MIDCOM protocol. In that case, why not simply limit the illustrations to
v4 hosts (or) v6 hosts only?

Including IPv6 transition mechanism into the document serves no purpose in
illustrating the MIDCOM protocol scenario. I believe, the entire 
section 2.4, with the exception of section 2.4.5, is not required. 
Unless you insist on including a V6-only network scenario, I would suggest
replacing the reference to V6 hosts with V4 hosts in section 2.4.5 - as
section 2.4.5 illustrates IPsec/IKE traversal scenario irrespective 
of whether both end-hosts are V6-only (or) V4-only.

Regards,
suresh

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 May 2001 15:54:45 -0400

Suresh,

you are correct that NAT-PT and similar techniques involving address
translation are necessary for interoperation between v4 and v4 hosts.
nobody has suggested otherwise.

however in order to avoid the interoperability problems caused by NATs
it is imperative that no address translation occur when using IPv6 
between v6-aware applications.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 May 2001 16:16:49 -0400

> illustrating the MIDCOM protocol scenario. 

Suresh,

I'm very puzzled by this statement.  Is it your belief that middleboxes
should not support untranslated IPv6 routing (including 6to4) in addition 
to any NAT or NAT-PT functions that they might support?  

Keith

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 11 May 2001 14:23:42 -0700 (PDT)

> nobody has suggested otherwise.

May be not explicitly. But, there was a suggestion to that effect in 
Christian's e-mail and in section 2.4 of his MIDCOM-scenarios draft.
For example, there was a statement that said that the use of NAT would 
simply disappear with the advent of IPv6 and that "Firewall/NAT" 
combination will simply turn into "firewall" only. Yet, there was
reference to RFC 3056 and 6to4 scenarios (i.e., V6 transition tools)
in a sentence right after this. Mentioning these 2 sentences (complete 
V6-only scenario and V6 transition scenario) in the same paragraph, 
yet having no reference to NAT-PT at best is misleading. 

Keith - the real point I was trying to get across was that the 
intoduction of V6 and V6 transition mechanisms in the MIDCOM-scenarios
document seemed like a red-herring and a diversion from the main theme
of the document. 

> between v6-aware applications.

I agree.

> Keith

regards,
suresh

=====

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 11 May 2001 14:34:33 -0700 (PDT)

> to any NAT or NAT-PT functions that they might support?  

Thats not at all what I am saying. I am saying that support of an 
untranslated V6 datagrams is orthogonal to the middlebox definition.
An intermediate device does not get to be called a "middlebox" merely
by virtue of transiting v4-traffic or V6-traffic. A middlebox has
application spcific processing requirements, in addition. 

For this reason, I dont believe, it is necessary to mention IPv6 
transition mechanisms in illustrating the MIDCOM protocol scenario.

regards,
suresh

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 11 May 2001 17:41:50 -0400

> document seemed like a red-herring and a diversion from the main theme

It's not - it's explicitly in scope.  Note that this
document is not a working group deliverable and is
intended to bring out architectural issues and requirements.

Melinda

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 May 2001 17:48:17 -0400

> combination will simply turn into "firewall" only. 

perhaps eventually.  but I don't think anybody thinks this will happen
immediately, or for many years.  in other words  it won't be the "advent"
of IPv6 that brings this about - it will only happen (if ever) after 
IPv6 is so widely deployed that IPv4 is redundant.  (much as DECnet
phase IV has become so redundant that nobody cares about PMR anymore)

> Yet, there was

seems like NAT-PT at least deserves mention  - a middlebox that can
support NAT-PT ought to be able to control those mappings via midcom
protocols just as much as one that supports NAT.
 
Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 May 2001 17:54:59 -0400

seems like the very purpose of a scenarios document is to envision 
possibilities, and this requires casting a wide net.  indeed, part
of the point is to examine things that are on the edge of, and 
perhaps even outside of the intended scope of midcom protocols,
just to see if there are any interactions that need to be considered
in the design of those protocols.

it would be bad if midcom somehow introduced additional barriers to 
an IPv6 transition.

Keith

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 11 May 2001 16:11:27 -0700 (PDT)

> intended to bring out architectural issues and requirements.
What specifically are the new architectural issues and requirements
(for MIDCOM) that came about as a result of illustrating the 6-to-4 
V6 transition mechanism or a V6-only network? 

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 11 May 2001 16:33:35 -0700 (PDT)

> phase IV has become so redundant that nobody cares about PMR anymore)
Sure, I agree.

> protocols just as much as one that supports NAT.

I agree. Perhaps, NAT-PT is the only V6-transition entity that will 
fit the definition of a middlebox. The WG focus so far has been
limited to Firewalls and V4-NAT. Perhaps the WG will beneft if the 
scenarios document included a NAT-PT based middlebox scenario.

> Keith

Thanks.

regards,
suresh

---

From: "Melinda Shore" <[email-masked]>
Date: Sat, 12 May 2001 07:44:53 -0400

> limited to Firewalls and V4-NAT. 

If it has it's been because of an oversight.  We talked
about v4<->v6 during the chartering process.  It's in 
scope.

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2001 12:25:07 -0500

Pyda,

I suspect that dual stack middleboxes themselves may prove to be very
important means of communication between v6-only and v4-only hosts,
making NAT-PT itself largely unnecessary. Whatever solutions midcom
invents need to deal with all likely scenarios, however, so I think
including v4/v6 coexistence in the scenarios is essential.

   Brian

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 14 May 2001 11:06:07 -0700 (PDT)

--- Brian E Carpenter <[email-masked]> wrote:
> making NAT-PT itself largely unnecessary. 

While dual-stack is a requirement, middlebox cannot do without NAT-PT
for such a communication (between V6-only and V4-only end-hosts).

>                                            Whatever solutions midcom

OK. Thanks.

regards,
suresh

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 May 2001 14:34:38 -0400

> making NAT-PT itself largely unnecessary.

Brian,

by "dual stack middleboxes" I take it you mean boxes that intercept
traffic at layer 4 or higher, rather than NAT-PT which operates
at layer 3?   you may be right, but I hope not.  NAT techniques
are already disruptive enough - interfering with higher layers
will just cause more problems.

I'm curious as to why you think this.  or if I've misunderstood
what you meant, please clarify.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2001 14:05:55 -0500

I believe that dual stack application level proxies and
gateways will be the primary mode of interworking between
IPv6-only networks and IPv4-only servers, for a large number 
of years.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2001 14:08:28 -0500

> for such a communication (between V6-only and V4-only end-hosts).

Yes it can, if it gateways or proxies the application.

    Brian

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 14 May 2001 12:20:44 -0700 (PDT)

Brian,

That sounds likely. But, these (proxies and gateways) donot the 
fit the definition of middleboxes the MIDCOM WG is looking at. 
The proxies and gateways, can be a reasonable choice to implement
MIDCOM agent functionality. Thanks for the clarification.

regards,
suresh

=====

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 May 2001 15:54:18 -0400

> IPv6-only networks and IPv4-only servers, for a large number

thanks for the clarification.  but given a choice between NAT-PT
which works across several (though by no means all) applications,
and a proxy which must be tailored for each application, why do 
you think the latter will be the primary mode? 

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2001 15:42:08 -0500

> you think the latter will be the primary mode?

Note that I said "IPv6-only networks" (i.e. not isolated IPv6-only
hosts). I tend to believe that IPv6-only networks will depend on
proxies and ALGs anyway, basically beacuse they will be cell phone
networks.

Melinda must be about to tell us we are off topic.

   Brian