Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt

From: Pekka Savola <[email-masked]>
Date: Tue, 4 May 2004 15:32:25 +0300 (EEST)

My own personal comments are below.

On Fri, 30 Apr 2004, Pekka Savola wrote:
> The intent is to WG last call it after having been published as WG
> item, and reach WG consensus on the requirements within a month.

(The document uses the word "authenticated" which is inaccurate,
but that was already to be changed to "registered", so I don't 
mention it again.)

substantial
-----------

                                                                   The
   tunnel set-up protocol must support both modes, however ISP deploying
   it may choose to only support one mode of operation.

==> this should be probably be its own paragraph, but a more important
issue: is this a requirement for a) the protocol, or for b) the
implementation of the protocol, or c) its deployment?

It looks like a) and c) but I could be wrong.

My argument is that IMHO the simple mode should be a must for implement, the
registered mode a should; and whatever the operators do is up to them, but
we could recommend them to not turn off the simple mode to keep it
interoperable.

....

5.1. Address and Prefix Delegation
                                                                                                                                
   The authenticated mode must support delegation of a single address or
   a whole prefix or a combination of both.

==> again, I've said this in the past, but IMHO prefix + address is not
interesting.  This is definitely not a must or even a should, IMHO -- and
should be scrapped entirely.  I assume the address would be assigned on the
point-to-point address (and such address is not even needed at all!).

...

   note: not clear what should be the mandatory authentication method.
   Clear text password is out. Digest-MD5 [2831] seems like a good
   choice.

==> I don't have a strong opinion either, but Digest-MD5 is not acceptable
-- MD5 must not be used for new protocols due to its collision weakness. 
Use SHA1 instead.

6.1 Scalability
                                                                                                                                
   The tunnel set-up protocol must be scalable.

==> We need a few more words than that to flesh out this requirement, I
think ;-)

semi-editorial/substantial
--------------------------

 "Assisted tunneling" is used in this document to described a
   transition mechanism where the parameters to configure a bi-
   directional tunnel between an end-node (or leaf network) and a router
   in the core of an ISP are negotiated through a tunnel set-up
   protocol. Although this negotiation phase can be automated, this
   remains different from transition mechanisms like 6to4 that is fully
   automatic or teredo/isatap which, once the IPv4 address of an initial
   server/router is configured  do not involve any further negotiation
   phase.

==> first, it may be inaccurate to talk about "negotiation", as you don't
_need_ to negotiate at all (any more than you need to negotiate with Teredo or
ISATAP).  The more controlled means may allow that, but it should not be
needed; therefore, I'd reword "negotiate" here, for example to like:

"Assisted tunneling" is used in this document to described a
   transition mechanism where the parameters to configure a bi-
   directional tunnel between an end-node (or leaf network) and a router
   in the core of an ISP are exchanged through a tunnel set-up
   protocol.  Although this exchange can be automated, [...]

==> I still think this is slightly inaccurate.  Teredo and ISATAP both
(practically) require more than configuring the v4 address of server/router:
they have to listen to the router advertisement from the server/router as
well.  So, it's one round-trip instead of zero round-trips.

Maybe reword to:

                Although this exchange can be automated, this
   remains different from a transition mechanism like 6to4 that is fully
   automatic.  Teredo and ISATAP, on the other hand, practically require
   receiving information about the available prefix or address from the
   server/router, comparable to the most simple form of assisted
   tunneling.

......

   In particular, the 'authenticated' mode defined in section 5
   enable access control to the IPv6 network where the other transion
   mechanism have to rely on out of band access control.

==> this has two typos (in enable "enable" and "mechanism), but this seems
slightly inaccurate and could be reworded to be like:

   In particular, the 'registered' mode defined in section 5
   enables explicit access control to the tunneled IPv6 connectivity,
   where other transition mechanisms have to rely on other kinds of control
   (e.g., access control based on the IPv4 address).

(but I'm not sure if that's 100% accurate either as e.g. Teredo includes
this authentication/origin data which can be used to restrict access to the
Teredo servers.)

...

   The tunnel established is "anonymous", the end-user does not provide
   any authentication to the server.

==> this probably should be reworded a bit, to like:

   The tunnel established is "anonymous" in a sense as the end-user does
   not register explicitly to the server. [...]

(note that the user could provide e.g. a hash which could be mirrored by the
server to give a proof of a kind -- the point is that the word
"authentication" seems too ambiguous here.)

4.1. Address Allocation

   This mode is used to provide IPv6 connectivity to a single host.
   Allocation of an IPv6 address (/128) to the end-node must be
   supported in this mode. This IPv6 address is "transient" and may
   change, but one may implement a mechanism to provide IPv6 address
   stability in this mode (e.g. cookie mechanism).

==> s/Allocation/Assignment/ (same later, also in section 6.9)
==> I see no reason to rule out sites from this, but we should not _require_
that from the protocol.  In other words, reword to:

   This mode is used to provide IPv6 connectivity to either a single host
   or a network.

   Assignment of an IPv6 address (/128) to the end-node must be
   supported in this mode. This IPv6 address is "transient" and may
   change, but one may implement a mechanism to provide IPv6 address
   stability in this mode (e.g. cookie mechanism).

   Assignment of an IPv6 prefix (e.g., /64 or /48) may be supported if
   feasible.

....

   The un-authenticated mode relies on out of band authentication.  It
   essentially offer the IPv6 service to any of its IPv4 customers.

==> s/un-authentication/non-registered/
==> "out of band authentication" is not clear: this refers to the
out-of-band with respect to IPv6 tunnel set-up session, but may be in-band
with respect to the IP connectivity; so reword:

   The non-registered mode does not require explicit authentication of the
   user.  Access control may be performed using e.g., IPv4 address.
   The mode essentially offers the IPv6 service to any of ISP's IPv4
   customers.

....

   In this mode, IPv4 return routability checks in the set-up phase of
   the tunnels seems to be a way to avoid some of these problems at the
   price of an extra round trip.

==> maybe add here:

                                  As the threat is specific to the
   ISP's ingress filtering deployment, the ISP should be able to specify
   whether such a check needs to be performed.

....

 However, as
   NAT traversal usually requires an extra layer of encapsulation, the
   tunnel set-up protocol must be able to detect automatically the
   presence of one or more NAT boxes in the path.

==> s/must/should/ (this is what 4.3 and 5.3 have at least, and IMHO a
should is sensible.)

==> do we want to test for the presence of a proto-41 forwarding NAT box? 
That would likely be complicated (would require extra transmission of
proto-41 packets)?  If we put that in, it's a "may" at most.

6.5 Latency in Set-up Phases
                                                                                                                                
   In certain type of networks, keeping tunnels active all the time is
   not possible or simply too expensive.

==> maybe spell out an example here or later in this section, like:

   not possible (e.g., when the host is mobile) ....

6.7 Traceability

==> this is not really traceability, reword; maybe like
"Provides Enough Information about Usage"

....

Once IPv6 is available natively in the access network
   connecting a customer, there is no reason to keep using tunnels. So
   the tunnel-setup protocol must have a provision to enable the ISP to
   signal the user to use native IPv6 instead.

==> I'd reword this "must" to a "should", but I don't feel too strongly
about this either way.

==> actually, this should probably be reworded as it's ambiguous. 
Obviously, if the user sees a route advertisement on the native link (or the
like), that should be used instead.  But is it the ISP's business to "stop"
the user to start using native v6 instead (if it doesn't work
automatically)?  At most, the mechanism should provide a means to show the
user a message that ISP is also providing native v6 service (possible e.g.
if the user switched to new service class, or replaced the NAT box)
even though the user is not obtaining it at the moment.

   [3053] A. Durand, P. Fasano, I. Guardini, D. Lento.,
          "IPv6 Tunnel Broker", January 2001.
                                                                                                                                
   [ISP]  Lind, M., "Scenarios and Analysis for Introducing IPv6
          into ISP Networks",
          draft-ietf-v6ops-isp-scenarios-analysis-01 (work in
          progress), February 2004.
                                                                                                                                
   [UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for
          Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work
          in progress), February 2004.

==> these probably belong ot the normative references section.

editorial
---------

   In an ISP network where IPv4 is dominant, some of the initial IPv6
   deployment phases consists of getting a prefix allocation from the
   RIR, and peering with other IPv6 ISP (or exchange points).

==> probably out of scope and could be removed?

      - assisted tunneling infrastructure to early adopters,
      - native IPv6 to customers where economically justified,
      - native IPv6 to all customers.

==> s/-/1)/, s/-/2)/, etc?

   Note that, as the addressing space used during the transition to
   native remains the same the customer routing, filtering, accounting
   [ISP, section 5.] stay the same, and there is no need to maintain any
   kind of relay.

==> s/same the customer/same, the customers'/ ?

   "Assisted tunneling" is used in this document to described a
 
==> s/described/describe/

   This document analyze the requirements for such a tunnel set-up
 
==> s/analyze/analyzes/

      - The device used as tunnel end point is located behind a customer
      owned NAT box that is also acting as a local DHCP server. In that
      case, the device IPv4 address may change after a reboot.

==> s/device/device's/
==> note that such behaviour is non-compliant with DHCP specs, but this is
not a hot issue for me.

  This may be regarded as a feature, but deployment of the service with
  this mode enable must be done carefully. In particular, security

==> s/enable// ?

   connectivity, transforming effectively the ISP into a IPv6 transit
 
==> s/a/an/

   authentication method must be supported. Other authentication MAY be
 
==> s/MAY/may/

   As in sectoin 4.4, IPv4 return routability checks could help blocking
 
==> s/sectoin/section/

6.2 Service discovery requirements
                                                                                                                                
==> s/discovery requirements/Discovery Requirements/ (same elsewhere where
applicable)

   set-up protocol must be able to abort immediately and display the
   customers a message explaining that no service is available.

==> s/customers//

   A client MAY choose not to send those messages (for example on ISDN
 
==> s/MAY/may/
==> (actually, I'd recommend also starting a new paragraph from "A client
..."

   There is a large number of Teredo clients already deployed, the
 
==> s/is/are/
==> s/,/, and/

   should be manage on the client side instead of the server side, that

==> s/manage/managed/

   Similar considerations as Teredo, section 7.2, applies to Isatap.
 
==> s/Isatap/ISATAP/

   technology, where traffic can be redirected to go from one place to
   another one.

==> s/another one/another/

9. Author Addresses
                                                                                                                                
==> s/Author/Authors'/

11. Non Normative References
                                                                                                                                
==> s/Non Normative/Informative/

    [2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

==> not used and can be removed.

-- 
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: Alain Durand <[email-masked]>
Date: Tue, 04 May 2004 10:32:14 -0700

Pekka,

thank you very much for the very detailed and very constructive 
comments.
responses in-line.

	 - Alain.

> It looks like a) and c) but I could be wrong.

I would say a) and b). b) for interoperability reasons. While deploying 
it, you turn on or off any features
you like or not.

> we could recommend them to not turn off the simple mode to keep it

If the ISP deploy the 'registered' mode and it has not been implemented 
in the client,
it does not work. That's why I think all implementations would have to 
support both
and the operation mode wo¨ld be decided by the ISP.

> point-to-point address (and such address is not even needed at all!).

This is again an operational decision that can be made only by the ISP.
This is why, IMHO, the protocol and its implementations should support 
both
modes.

> -- MD5 must not be used for new protocols due to its collision 

Why not. is it an IESG policy?

> ==> We need a few more words than that to flesh out this requirement, I

really? ;-)

> semi-editorial/substantial

ok.

>    server/router, comparable to the most simple form of assisted

ok

>    (e.g., access control based on the IPv4 address)

ok

>    not register explicitly to the server. [...]

ok

>    Assignment of an IPv6 prefix (e.g., /64 or /48) may be supported if

As it seems that there is a (weak) consensus to leave the 
non-registered mode,
I agree with your suggestion.

>    The mode essentially offers the IPv6 service to any of ISP's IPv4

ok

>    whether such a check needs to be performed.

ok

> ==> s/must/should/ (this is what 4.3 and 5.3 have at least, and IMHO a

Not sure. I think the protocol and its implementation MUST
support the detection, but the deployment MAY turn it off.
i should clarify this.

> proto-41 packets)?  If we put that in, it's a "may" at most.

I hadn't thought of that... Is it the case that if proto-41 forwarding 
is in place
then the communication would be un-differentiable from a non nated one?

>    not possible (e.g., when the host is mobile) ....

nothing to do with mobility but with the charging method (i.e. by the 
minute?).
But I agree, more text is needed.

> "Provides Enough Information about Usage"

Is this not the definition of traceability?

> ==> I'd reword this "must" to a "should", but I don't feel too strongly

neither do I. Does anybody else have an opinion?

> like), that should be used instead.

No, this is not enough. Example: I may have a local router on my 
ethernet link that advertises
an internal prefix, but this does not mean that I can use it to get 
external
connectivity and have to give up my modem line.

> But is it the ISP's business to "stop"

Yes. This is the concern I have, ISP now offer native, but the box is 
still configured
to use the tunnel.

> ==> these probably belong ot the normative references section.

I never understand what goes where... What is you rationale?

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 May 2004 23:35:04 +0300 (EEST)

in-line... omitting the parts where we agree..

On Tue, 4 May 2004, Alain Durand wrote:
> I would say a) and b). b) for interoperability reasons. While
> deploying it, you turn on or off any features you like or not.

You mean, that's the goal?  I agree.  (The text currently seems to say 
a + c).

> > My argument is that IMHO the simple mode should be a must for
> > implement, the registered mode a should; and whatever the
> > operators do is up to them, but we could recommend them to not
> > turn off the simple mode to keep it interoperable.
> 
> If the ISP deploy the 'registered' mode and it has not been
> implemented in the client, it does not work. That's why I think all
> implementations would have to support both and the operation mode
> would be decided by the ISP.

It would be beneficial to support both, yes, but if this was to be 
applied e.g., in 3GPP or mobile environments (just to take an 
example), I'd guess that there might be some interested in simplifying 
the client.

Similarly, as providing service over a tunnel is more or less a 
"tryout" service in any case (I don't think many ISPs would see that 
as "production"), my personal view is that the most who would want to 
deploy something like this in the first place would actually want the 
simple mode.  (And if they're OK with all the registration etc. 
_process_ and procedures, many could use L2TP or deploy dual-stack in 
any case.)

The simple form is also something that could be implemented and turned 
on by default on hosts (when v6 is turned on, if not on by default, 
that is).

That's why I think "simple" form is criticial, and the registered mode 
interesting for "power users" but not necessarily for all that many 
ISPs for production use.

> > ==> again, I've said this in the past, but IMHO prefix + address
> > is not interesting.  This is definitely not a must or even a
> > should, IMHO -- and should be scrapped entirely.  I assume the
> > address would be assigned on the point-to-point address (and such
> > address is not even needed at all!).
> 
> This is again an operational decision that can be made only by the
> ISP. This is why, IMHO, the protocol and its implementations should
> support both modes.

Note that I'm not arguing for doing address assignment or prefix 
delegation, but I was just stating that doing _both_ for a single 
session (as it appears to read) does not seem like a useful 
requirement.

> > ==> I don't have a strong opinion either, but Digest-MD5 is not
> > acceptable -- MD5 must not be used for new protocols due to its
> > collision weakness.  Use SHA1 instead.
> 

Yes. draft-iesg-tcpmd5app-00.txt provides some background to this, but 
focuses on TCP-MD5 only.

> > ==> We need a few more words than that to flesh out this requirement, I

Good that we agree ;-)

[[clipping comments you agree with]]
> support the detection, but the deployment MAY turn it off.

This is a bit in odds with 4.3 and 5.3 then, as those seem to be 
closer to a 'should'.

My own view is that in some environments it might be acceptable to 
just always use UDP, to avoid certain hassles of toggling between 
proto-41 and UDP -- but as this causes overhead, we should try to 
avoid the overhead if feasible.  Hence a (strong) should.
 
> > ==> do we want to test for the presence of a proto-41 forwarding
> > NAT box? That would likely be complicated (would require extra
> > transmission of proto-41 packets)?  If we put that in, it's a
> > "may" at most.
> 
> I hadn't thought of that... Is it the case that if proto-41
> forwarding is in place then the communication would be
> un-differentiable from a non nated one?

It's slightly different: the "internal IP address" set in the packets 
to detect whether NAT was on the path or not would tell there is a 
NAT, and would result in (an unnecessary) fallback to UDP.

So, to cater for that situation, the logic would have to be like:

 1) send the packet to the server with "my own address" set
 2) the server notices that "my own address" and the source address 
    are not the same.
  2.1) the server tries to send an IP-proto-41 packet to the source 
       address in any case; if it doesn't hear back soon, retry with 
       UDP.
  2.2) failing that, just send the packet on UDP.

  2.3) in both cases, activate the NAT keepalive sequence.

It seems to me that the fallback in 2.1) might add some substantial
code in case the NAT doesn't forward proto-41, especially if the
negotiation/parameter exchange would otherwise conclude after sending
the packet (i.e., this would require at least 1.5 roundtrips to verify
a host behind a NAT got the information, and if it didn't, at least 2
roundtrips -- using just UDP could be done with 1 roundtrip.)

Obviously, this kind of "forwarder detection check" could possibly be 
implemented separately, and would be indicated as a flag from the 
client, but that might have some minor failure modes as well.

> nothing to do with mobility but with the charging method (i.e. by
> the minute?). But I agree, more text is needed.

Yes, the text focused on the charging model, but section title on 
Set-up latency is important for mobile etc. as well, so it should be 
mentioned somehow.
 
> Is this not the definition of traceability?

I, at least, think of traceability as "a way to trace the usage of a 
user or IP address" which is a bit different?

> > Obviously, if the user sees a route advertisement on the native
> > link (or the like), that should be used instead.
> 
> ethernet link that advertises an internal prefix, but this does not
> mean that I can use it to get external connectivity and have to give
> up my modem line.

OK -- what it could probably check is default route with medium 
or high preferece (and your case, one should use low preference or 
more specific routes).

> > But is it the ISP's business to "stop" the user to start using
> > native v6 instead (if it doesn't work automatically)?  At most,
> > the mechanism should provide a means to show the user a message
> > that ISP is also providing native v6 service (possible e.g. if the
> > user switched to new service class, or replaced the NAT box) even
> > though the user is not obtaining it at the moment.
> 
> Yes. This is the concern I have, ISP now offer native, but the box
> is still configured to use the tunnel.

Right.  But is it a good idea to "cancel" service like that?  I mean,
in most cases, it's fine if the user is able to (automatically!) get
v6 using other means -- but if it's not automatic, the user would be
left without service altogether!

In other words, the ISP can cease tunneling service by taking down the 
tunnel server or making sure it provides no further allocations if the 
ISP wants to be "draconian".  The most we should probably do is have a 
means for the client software to state that native v6 is available 
(whether mentioned by the server or not)..

> I never understand what goes where... What is you rationale?

Normative refs are usually those which must be read in order to
understand this particular document, or must be implemented in order
to implement this spec.

In this particular case, you seem to be citing at least [ISP] and 
[UNMANAGED] in such a way that this would seem warranted.  

(One feature of normative refs is that they block publication, but as
you cite the scenarios from those in a particular fashion, this
document should not go forward unless those scenarios and text are
final.)

---

From: Alain Durand <[email-masked]>
Date: Tue, 04 May 2004 18:09:51 -0700

> in-line... omitting the parts where we agree..

I'm glad we are converging. See inline response were there is still 
discussion.

> interesting for "power users" but not necessarily for all that many

I'll take this discussion to a separate thread.

> avoid the overhead if feasible.  Hence a (strong) should.

I honestly do not believe that checking the presence of a NAT
and firing UDP encapsulation if it is there is such a big deal...
So I believe it is worth a MUST, as the payoff is important
by reducing the overhead.

> client, but that might have some minor failure modes as well.

How widely is IP proto 41 forwarding deployed? If it is not much,
I suppose that forcing an extra layer of encapsulation would
not be that terrible... and also would allow for more than one
tunnel to go through the NAT box.
So, I do not think that detecting NAT proto 41 forwarding is
an important requirement.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 5 May 2004 09:44:14 +0200

Hi Alan,

Is difficult to say, but my survey (obviously not a precise one, lack of resources, lack of replies from vendors, and lack of chances to test myself all the models in the market !), indicates that 80-85% of the products there support proto-41-forwarding.

So I think is a MUST.

Regards,
Jordi

----- Original Message ----- 
From: "Alain Durand" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 05, 2004 3:09 AM
Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt

> an important requirement.

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Florent Parent <[email-masked]>
Date: Wed, 05 May 2004 06:24:11 -0400

(text removed)

> an important requirement.

I think we should keep this simple (no ip-proto 41 fowarding detection). 
Instead, the end-user can optionally select how the tunnel is established:

By default, client requests a "wildcard" encapsulation (NAT detection 
enabled):
- If no-NAT, proto 41 is used
- If NAT, IPv6 over UDP is used

The client can also be configured to request a specific encapsulation (NAT 
detection is off):
- If the user knows that its NAT supports proto41 forwarding, then request 
proto 41 tunneling.
- The client can also request IPv6 in UDP tunneling, no matter in which 
environment it is. This may be the case where the overhead is considered 
insignificant

Florent

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 5 May 2004 16:34:00 +0200

Hi Florent,

I believe that asking the customer to do so is, in the majority of the cases too much. While doing it automatically is very simple and the extra work on the client side implementation pays for the value added. In the worst case it should be an implementation issue (so a SHOULD ?), and the market will decide with product is best ;-)

Regards,
Jordi

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 05 May 2004 16:59:32 +0200

On Wed, 2004-05-05 at 16:34, JORDI PALET MARTINEZ wrote:
> Hi Florent,
> 
> I believe that asking the customer to do so is, in the majority of the
> cases too much. While doing it automatically is very simple and the
> extra work on the client side implementation pays for the value added.
> In the worst case it should be an implementation issue (so a SHOULD
> ?), and the market will decide with product is best ;-)

Florent mentioned that user-side-configuration is optional, that is
why he mentioned the 'wildcard encapsulation'.

> > environment it is. This may be the case where the overhead is considered 

To rephrase:

The configuration protocol can easily see if it is a NAT or not.

Clients MAY request ANY, UDP or Proto-41 as encaps.

When the encaps is ANY the client sends the IP it think it has globally
to the configuration server, which compares it with the actual
connection origin, different -> NAT -> use UDP. Otherwise it can safely
assume proto-41.

Additionally:

Clients MAY also check if they have an RFC1918 address, they then also
know that they are behind a NAT.

Greets,
 Jeroen

---

From: Florent Parent <[email-masked]>
Date: Wed, 05 May 2004 07:13:42 -0400

> (whether mentioned by the server or not)..

Detecting native IPv6 availability in the client makes sense: Stop using 
the tunneled service when a link is IPv6 configured from a RA.

The case Alain mentionned where (local router advertising RA but not usable 
for external connectivity) is a special case. The client may have an option 
to request a tunnel even if native IPv6 is available. But I would leave 
that optional (may).

Florent

---

From: Florent Parent <[email-masked]>
Date: Wed, 05 May 2004 07:17:54 -0400

> know that they are behind a NAT.

In fact, I would not make any assumptions about the IPv4 addresses. This 
service could be offered inside a large privately-addresses network, where 
both the clients and server are using rfc1918 addresses, therefore no NAT 
in the path. IMHO, its best to let the server do the detection of whether 
an address translation occured.

Florent

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 05 May 2004 17:56:44 +0200

> an address translation occured.

That is true and another scenario could be:

{Internet} --- {ISP} --- | NAT | --- [TB/6to4/ISATAP/...] ---- {clients}

Thus I revoke that thought ;)

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 May 2004 21:26:34 +0300 (EEST)

On Wed, 5 May 2004, JORDI PALET MARTINEZ wrote:
> I believe that asking the customer to do so is, in the majority of
> the cases too much. While doing it automatically is very simple and
> the extra work on the client side implementation pays for the value
> added. In the worst case it should be an implementation issue (so a
> SHOULD ?), and the market will decide with product is best ;-)

I think this thread has very clearly shown that doing it automatically
is not simple at all so that it would work under all cases.