Subject: comments on draft-durand-v6ops-assisted-tunneling-requirements-00 .txt

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Wed, 14 Apr 2004 21:37:27 +0200

Hi

I have some comments on the draft. Section 2 says:

  - The customer configuration may be diverse, and not necessarily
       predictable by the ISP. The following cases must be supported:
         - a single node,
         - a leaf network,
         - using a globally routable IPv4 address,
         - behind a NAT,

However it also says (later in section 2):

   Althought the main focus of this document is the ISP scenario,
   assisted tunneling is applicable in all the other scenarios:
   unmanaged, enterprise and 3GPP.
   ...
   In 3GPP networks, assisted tunneling can be used in the context of
   dual stack UE connecting to IPv6 nodes through a 3GPP network that
   only supports IPv4 PDP contexts [3GPP, 3.1].

There seems to be a contradiction when considering 3GPP networks,
since the customer does not have a NAT in the customer equipment
(i.e. mobile terminal). Therefore the tunneling can be terminated
within the mobile operator's network and never goes through a NAT.
That's a good thing since we wouldn't have to pass even more traffic
(v6 tunnelled traffic) through NATs in this scenario. For the same
reason the following consideration on ISATAP does not apply to 3GPP
networks (also described in the draft reference [3GPP]):

   7.3 ISATAP

   Similar considerations as Teredo, section 7.2, applies to Isatap.
   However, as Isatap can not work accross NAT, it is of much less
   interest in the framework of this document.

I think that to make this draft applicable to 3GPP networks some
substantial changes would be needed such as the removal of the NAT
assumption.

/Karim

---

From: Alain Durand <[email-masked]>
Date: Wed, 14 Apr 2004 15:07:28 -0700

Karim,

Thank you for your comment.
See response inline.

	- Alain.

> networks (also described in the draft reference [3GPP]):

I think there is a confusion in the lit of cases that must be supported.
This is an ORed list, not an ANDed list, that is we need to design a
protocol that can support all those cases but each of them can happen
separately. Maybe if we reword the text as:
The following cases must be supported:
- the customer has a single node or a complete leaf network
- those nodes are either using globally routable IPv4 addresses
   or are behind one or more NAT.

Note that this does not mean that nodes with globally routable IPv4
addresses will always do IPv6/udp/IPv4 encapsulation (or something like 
that),
it means that the tunnel set-up protocol will determine if a NAT box is 
in the way
and if it is the case, an extra layer of encapsulation is necessary, 
and it will
configure the tunnel accordingly.

So, in the 3GPP case where the customer will have one device with one 
global IPv4 address,
there will be no NAT and there would be no extra encapsulation.

I think it is better to design a single protocol that can accommodate 
many
scenarios than designing a protocol for each scenario.

> substantial changes would be needed such as the removal of the NAT

Again, there is no assumption that a NAT will always be there. There is 
an assumption that
a NAT may be there, that it will be detected and the encapsulation will 
be different.

I hope this clarifies the points you raised.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 15 Apr 2004 01:11:37 +0300 (EEST)

> substantial changes would be needed such as the removal of the NAT

I do not see the contradiction.

The document just basically says, "we want to support all the 
scenarios, whether it goes through a NAT or not".

In the case of 3GPP, it doesn't go through NAT, but the requirements 
are equally applicable.

On the other hand, as I read it, section 7.3 basically says "ISATAP 
could be supported, but as it is not applicable through a NAT, it 
would only be usable in the scenarios where there is no NAT, so it 
might not be worth the effort plug ISATAP support in the tunnel 
server clients/servers."

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 14 Apr 2004 18:37:46 -0400

Karim,
 "dumb questions":
- NAT were not planned to happen. IPv4 was not designed with NAT. NAT
happened. Nobody can control the deployment of NATs.
- now, when you say: 
 + "the customer does not have a NAT in the customer equipment", how can we
enforce/ensure that this will never happen?  

It appears to me that NATs are everywhere, even in places that tried to
avoid them.(The world's richest organisation in terms of IPv4 addresses
have so many NATs you can't think of...). And you can't restrict the
deployment of NAT: the operator of a network (3G, wireless, wired, etc...)
may deploy a NAT as its own way. How would 3G be able to enforce the
non-existence of NATs?

Does the assumption of no-NAT really stand?

excuse-me if these are dumb questions.

Marc.

> substantial changes would be needed such as the removal of the NAT

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

---

From: Fred Templin <[email-masked]>
Date: Wed, 14 Apr 2004 15:44:02 -0700

I guess I'll have to take exception to the text of section 7.3 in the
current document version. The sentence:

  "However, as ISATAP cannot work accross NAT, it is of much
   less interest in the framework of this document."

seems more a statement of opinion rather than a statement of fact
born out through analysis.

My suggestion is to simply remove this sentence, since doing so
would remove any opinions/presumptions w/o altering the overall
technical content of the section.

Fred
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Wed, 14 Apr 2004 16:02:57 -0700

> born out through analysis.

I remenber the NGtrans days when NAT traversial was specifically
a non goal for Isatap. Did things changed?

	- Alain.

---

From: Fred Templin <[email-masked]>
Date: Wed, 14 Apr 2004 16:18:30 -0700

> a non goal for Isatap. Did things changed?

What I recall is being badgered by someone in a position of
authority to assume that position, so your question could
perhaps better be redirected.

Fred
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Wed, 14 Apr 2004 17:31:47 -0700

Fred,

I read isatap-20 draft, section 8.1.1 NAT Traversal.

Could you explain me how this is suppose to work in the following 
situation:

Node A 192.168.1.2 |--  NAT (IPa) -------- (IPb) NAT --| Node C 
192.168.1.2
Node B 192.168.1.3 |                                                    
      | Node D 192.168.1.3

	- Alain.

---

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Thu, 15 Apr 2004 18:40:22 +0200

>scenarios, whether it goes through a NAT or not".

A solution requiring NAT traversal will end up being very different
from one not requiring it, so it is an important point IMO.
Ths draft says that the solution must support NAT traversal, and this
feature is not applicable to 3gpp. So this requirement would
end up in a solution that is designed for something that is not
useful (and potentially a disadvantage) for 3gpp networks. I see
that as a problem.

>In the case of 3GPP, it doesn't go through NAT, but the requirements 

I disagree. The requirement that the solution must work through NATs
is not applicable to 3GPP. The fact that the NAT traversal solution
may also happen to work in 3GPP doesn't mean it is the right thing to
be deployed there.

>might not be worth the effort plug ISATAP support in the tunnel 

Well it says that "it is of much less interest in the framework of
this document.". This is essentially saying "not needed".
Since the document describes tunnelling requirements also applicable
to 3GPP I don't think this wording applies to ISATAP.

/Karim

---

From: Alain Durand <[email-masked]>
Date: Thu, 15 Apr 2004 09:57:33 -0700

IP support routing. 3GPP does not support routing in the handset.
Does this makes IP not suitable for 3GPP?
No. You simply do not use this feature.
Same analogy applies here. We are not trying to design something
that works only in the 3GPP case, but can works elsewhere as well.

Btw, Marc's Blanchet point is very good: how can you be sure that
there never will be any NAT?

	- Alain.

---

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Thu, 15 Apr 2004 19:04:36 +0200

Hi Marc

>enforce/ensure that this will never happen?

Well, now there is a deployable alternative with IPv6.
It's impossible to be 100% sure of things, but saying that it
is OK to put a NAT in a mobile phone at the time when mobile
manufacturers are going to dual-stack terminals doesn't make
sense to me.
  
>may deploy a NAT as its own way. How would 3G be able to enforce the

There are no NATs in mobile phones today since there is no use
for them and I sure hope never to see them. I think most people
would agree. So there is nothing today that hints at this
development and I think we should not be proposing solutions
that are compatible with this.

Mobile manufacturers will be shipping dual-stack mobile terminals
and that is what we should be (and are) favouring. If a PAN is
needed behind the terminal then it's an excellent case for using
IPv6. Supporting NAT traversal mechanisms in this scenario seems
very dangerous to me and it doesn't help since we really want to
reduce the use of NATs if possible, not increase the traffic
through them.

>Does the assumption of no-NAT really stand?

I think it does.

/Karim

---

From: Alain Durand <[email-masked]>
Date: Thu, 15 Apr 2004 10:23:42 -0700

On Apr 15, 2004, at 10:04 AM, Karim El-Malki (HF/EAB) wrote:
> would agree.

Let me disagree.
The scenario is a remote location or road warrior where the only 
possible/realistic
connectivity is through 3GPP/3GPP2. That may be an intermittent case 
when 802.11
is not available.
I'd like to get a 3GPP network attachment on a computer 
(PCMCIA/PCI/USB/Bluetooth...)
or 802.11 access point and run a NAT there. It would act as a router 
for the rest of my network.
Now, any device within my network that desire to get IPv6 connectivity
will have to go through that NAT.

	 Alain.