[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Karim,

Thank you for your comment.
See response inline.

- Alain.

On Apr 14, 2004, at 12:37 PM, Karim El-Malki (HF/EAB) wrote:

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]):


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.


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.

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.