Subject: draft-palet-v6ops-auto-trans-01 comments

From: Pekka Savola <[email-masked]>
Date: Sun, 1 Aug 2004 17:44:01 +0300 (EEST)

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

In section 3.3, this doc goes on to state that building v6 tunnels over UDP
is not always possible as some middle boxes don't forward those packets.

I'd argue that this is a scenario we want to declare out of scope.  If such
a box really exists, it's more likely than not that the user is not supposed
to punch holes in the NAT/firewall.  We can simplify this a lot if we can
remove whole section 3.3 and its subsections on HTTP, TCP or other tunnels.

semi-substantial
----------------

   A number of transition mechanisms have been defined already: Teredo,
   TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, DSTM, etc.  All of them work
   when the host willing to get IPv6 connectivity has a public IPv4
   address.  Even some of them also work when the host is located behind
   a NAT box that allows proto-41 forwarding [3].  However there are
   other kind of NAT boxes that prevent the current transition
   mechanisms to work, so there is a gap that could be filled with new
   kind of solutions, possibly layer 2 or layer 4 tunnels.

==> the sentence starting "However" seems to imply that NAT boxes which
don't allow proto-41 forwarding don't work with these mechanisms, requiring
new ones... which is not quite the  case for Teredo, TSP, and STEP at
least.. requires rewording.

   loop
        detect_scenario
        if (native_IPv6_available and native_priority)
                use_native_IPv6_connectivity
        else
                if (first_check or performance_check_allowed)
                        check_performance
                        use_best_mechanism
                endif                                             
        endif
        configure_connectivity
        wait (link_check_timeout)
   endloop

==> this algorithm doesn't actually work (AFAICS) because use_best_mechanism
is inside the loop.  Shouldn't it be outside the loop?  Or did you mean that
it selects the best of *so far* configured/tested mechanisms?

  A possible list of mechanisms to be checked, ordered by preference
   could be:

   7.  DSTM

==> I think you can strike this from the list, because this draft discusses
how to get v6 everywhere... DSTM already assumes v6, and is a solution for
getting v4.

3.2  Change of transition mechanism

==> this section, or something close to it, should probably discuss when it
makes sense to have multiple transition mechanisms active at the same time. 
For example, you might still want to activate 6to4 even if you have a
tunnel, for optimization purposes.

   1.  Nodes that do not need to maintain the IPv6 address assigned from
       their home TS.  They are typically nomadic users who get
       connectivity to "passive" Internet users (browsing, emailing,
       etc.), but do not need to be "identified" from Internet
       (nevertheless this situation is changing with next generation p2p
       applications, VoIP, etc.).

==> it's actually not as simple as that.  You assume that the identification
would have to be done based on the IP address.  In many cases, that's
probably a bad choice, but should be done e.g., based on DNS or some p2p
naming/rendezvous system.  IMHO, we want to get to the point where the IP
address you have doesn't make much difference, because you're using layers
of indirection like DNS... and the only thing you may need to worry about is
connection survivability which is what MIPv6 and multi6 designs will fix if
you don't get the same IP address.

   2.  Nodes that need to maintain the IPv6 address assigned from their
       home TS.  Users belonging to this group are typically users with
       either server or peer-to-peer applications, devices that need to
       be tracked (cars, suitcases, etc.), etc.

==> here, again, you make an assumption that tracking would have to be done
based on the IP address.  That's not necessarily the case, but in this
particular scenario, I the more natural way would be to actually track it.

       *  Mobility capability should be an option that should be
          configured by means of the installation wizard.  If chosen,
          the first time that the auto-transition algorithm is run, it
          must check if a Home Agent (HA) exists either in the current
          IPv6 network or in the TS.  In fact, this option should
          condition the order of searching for the best transition
          mechanism to get IPv6 connectivity.  In this way, only
          mechanisms compatible with the presence of HA should be taken
          into account (mechanisms providing static IPv6 network prefix
          like TB, TSP, ISATAP, etc.).

==> I don't quite understand how you mix MIPv6 into this.  I didn't
understand the second sentence (starting with "If chosen,..") or the last
sentence (I mean, any mechanism is compatible with HA, as if you have HA,
you can have whichever address at all because it's just your CoA).

 On the other hand, the
          auto-transition algorithm should discard transition mechanisms
          that build the IPv6 network prefix from the IPv4 address
          (6to4, TEREDO, etc.).  This is required because it is no
          possible the deployment of the HA into the same IPv6 network,
          so no mobility features would be possible.

==> I didn't quite understand the second sentence here either..

5.  Network Managed Transition

==> this section seems overlongly long and detailed.. I think the basic
thing you're saying is that the network could provide a means to help the
user choose their mechansism (my example: e.g., a DNS record),
describing different options and possibly giving preferences as well.
This is in particular because policy-based networks didn't really get into a
good swing and get deployed.  Thus, I'd only keep the first 1-2 paragraphs,
and those from the end starting with "Whether the network provides"..

editorial
---------

   The main goal is to facilitate the IPv6 deployment in a seamless way
   for devices, users and applications.  Lots of devices and
   applications around us will benefit obtaining IPv6 connectivity
   everywhere:

==> s/benefit/benefit from/

  o  End devices: Devices that do not intend to provide IPv6
      connectivity to others.  They are typically devices that would get
      IPv6 connectivity by means of Router Advertisement if they were 
      attached to a native IPv6 scenario.

==> remove "scenario".

      etc.  They should provide native IPv6 connectivity to the whole
      network(s) located behind them by announcing an IPv6 prefix.  With
      this approach this kind of devices will be plug-and-play,

==> s/this/these/

  We should understand that the auto-transition goal is to facilitate
   an adecuate transition to IPv6.  Towards that, it tries to

==> s/adecuate/adequate/

   given scenario, which may be not the perfect one.  Actualy
   implementing a perfect auto-transition solution could be a very
   complicated,

==> s/Acutaly/Actually/

 in the case it happens, could
   bring us the paradigm that there is no anymore an incentive for
   native IPv6 connectivity, which clearly is in contradiction with this
   memo goal and in general the IPv6 deployment one.

==> reword the end: s/memo/memo's/ and the last few words somehow.

   The auto-transition algorithm may take into account not only the   
   results shown in [8], because it is also possible a wider focus to
   select the best transition mechanism to be used.

==> something missing in the middle line -- I can't parse it?

  o  detect_scenario: This task deals with detecting the scenario where
      the device willing to have IPv6 connectivity is located.  It could
      check if native IPv6 is available, if a public IPv4 address is
      available, if a NAT is being used and what type, if there is a
      proxy or firewall, or if other protocols can be operated.

==> I'd do s/and what type/(and possibly what type)/ because it might not be
feasible to do that in auto-trans, if the mechanism has to detect the NAT
type (like Teredo) in any case -- or were you referring to whether it
forwards proto-41 or not?

 So, for
       instance, if the device running the auto-transition algorithm
       needs to contact with a TB different to the actual one and it
       requires user authentication, the process should be transparent
       to the user.

==> I didn't quite understand which TB is the "actual one"

If native IPv6 connectivity is provided 
   by the ISP and used, this TS will be obviously the link end point and
   no further work is required.

==> this is a slighly confusing way to say that if you have native v6, you
don't run any tunnel (except for special cases, e.g., 6to4),
and you don't even need to discover the end-point.

  Different transition mechanisms have different IPv6 type of end
   points.

==> "IPv6 type of end point" was a bit odd confusing word selection.

4.  Nomadicity Considerations

==> would it be useful to split the two nomadicity cases to their own
subsections?

       *  TSs that do not require authentication process.  They are TSs
          that provide IPv6 connectivity and they do not make any
          authentication process (TEREDO, 6to4, etc.).  This approach
          does not represent any innovation, so the auto-transition
          algorithm just contact to the TS and the IPv6 connectivity is
          obtained.

==> "doesn't represent any innovation" -- I don't understand, remove ?

 If there are not such
          agreements, automatic connectivity is not possible and the   
          auto-transition algorithm has to options:

==> s/to/two/

-- 
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: Florent Parent <[email-masked]>
Date: Sun, 01 Aug 2004 16:30:02 -0700

-- On Sunday, August 01, 2004 17:44:01 +0300, Pekka Savola wrote:

> substantial
> -----------
>
> In section 3.3, this doc goes on to state that building v6 tunnels over
> UDP is not always possible as some middle boxes don't forward those
> packets.
>
> I'd argue that this is a scenario we want to declare out of scope.  If
> such a box really exists, it's more likely than not that the user is not
> supposed to punch holes in the NAT/firewall.  We can simplify this a lot
> if we can remove whole section 3.3 and its subsections on HTTP, TCP or
> other tunnels.

I agree.

IPv6 over UDP (or TCP if one cares) is used to get IPv6 across NATs in the 
case where this is allowed/wanted/not prohibited. We don't want to require 
a protocol to do firewall traversal.

BTW, the most of the tunnel mechanisms described in this section will have 
the same problem as, say, IPv6 over UDP if the middlebox has strict 
filtering policy.

Florent

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sun, 1 Aug 2004 22:42:59 -0700

Hi Pekka,

See my reply below, in-line.

Regards,
Jordi

---- Original Message ----
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, August 01, 2004 7:44 AM
Subject: draft-palet-v6ops-auto-trans-01 comments

> substantial

I partially don't agree. I agree that some times the "network administrator" (i.e., enterprise), don't want to the user to punch the NAT/firewall, but in some circumstances, the issue is more a non-technical knowledge of the user to do that, so we need to describe a solution (which can be or not provided in the specific implementation).

> don't allow proto-41 forwarding don't work with these mechanisms,
> requiring new ones... which is not quite the  case for Teredo, TSP, and
> STEP at least.. requires rewording.

Yes, you're right. I will find a better wording to avoid that misunderstanding. I will also put concrete references to all those mechanisms.

> ==> this algorithm doesn't actually work (AFAICS) because
> use_best_mechanism is inside the loop.  Shouldn't it be outside the loop?
> Or did you mean that it selects the best of *so far* configured/tested
> mechanisms? 

Yes, once we detect the scenario, and what mechanisms are possible, and which one is "best", then we actually enable it.

> ==> I think you can strike this from the list, because this draft
> discusses how to get v6 everywhere... DSTM already assumes v6, and is a
> solution for getting v4.

Yes and not ... we are considering to extend this document to cover both sides of the history ... then DSTM could play an important paper there.

> ==> this section, or something close to it, should probably discuss when
> it makes sense to have multiple transition mechanisms active at the same
> time. For example, you might still want to activate 6to4 even if you have
> a tunnel, for optimization purposes.

You mean activate multiple transition mechanism and actually make use of both ? Not really sure if we want to put the host in a multi-homing situation. Is this good ?. Or I'm not figuring out what you are trying to say ?

> ==> it's actually not as simple as that.  You assume that the
> identification would have to be done based on the IP address.  In many
> cases, that's probably a bad choice, but should be done e.g., based on
> DNS or some p2p naming/rendezvous system.  IMHO, we want to get to the
> point where the IP address you have doesn't make much difference, because
> you're using layers of indirection like DNS... and the only thing you may
> need to worry about is connection survivability which is what MIPv6 and
> multi6 designs will fix if you don't get the same IP address.

Yes, this may require further clarification/work. But today, for stable services, most of the time you use DNS, and this is associated to a specific (not dynamic) IP address ...

> ==> here, again, you make an assumption that tracking would have to be
> done based on the IP address.  That's not necessarily the case, but in
> this particular scenario, I the more natural way would be to actually
> track it. 
> 

Yes, we mean that if MIPv6 is choosen as an option (either automatically or by the user by means of a wizard), then ... The problem here is if the user has access to a HA or not.

> ==> I didn't quite understand the second sentence here either..

I need to check with the previous version, because I'm also confused here myself ;-)

> This is in particular because policy-based networks didn't really get
> into a good swing and get deployed.  Thus, I'd only keep the first 1-2
> paragraphs, and those from the end starting with "Whether the network
> provides".. 
> 

Our point here is precisely that the provision of PBN could motivate the ISPs to start the transition, because they can take the opportunity to do other "policy" based services at the same time. Is not only a DNS record, but a managed transition that also provides the ISP the way to control the process and provide higher quality of the transition service.

> ==> s/benefit/benefit from/

Ok.

>       attached to a native IPv6 scenario.

I will use network instead of removing scenario.

>       this approach this kind of devices will be plug-and-play,

Ok.

>    an adecuate transition to IPv6.  Towards that, it tries to

Ok.

>    implementing a perfect auto-transition solution could be a very

Ok.

> ==> reword the end: s/memo/memo's/ and the last few words somehow.

Ok.

> ==> something missing in the middle line -- I can't parse it?

What I try to say is that we don't believe the auto-transition should be limited to the mechanism described in [8]. Will reword it to make it clearer.

> ==> I'd do s/and what type/(and possibly what type)/ because it might not
> be feasible to do that in auto-trans, if the mechanism has to detect the
> NAT type (like Teredo) in any case -- or were you referring to whether it

I don't understand why you say that auto-trans can't do that ? Or you mean that is not useful because is done already by the mechanism itself ? But if so, that only happens once the mechanism is launched, and auto-trans goal is to select the right mechanism before its started.

> ==> I didn't quite understand which TB is the "actual one"

In the case that you are already connected, for example, to a TB and you're moving to a network that offers a better TB option (nearer one).

> and you don't even need to discover the end-point.

Ok.

> ==> "IPv6 type of end point" was a bit odd confusing word selection.

Probably should be "different IPv6 end points".

> ==> would it be useful to split the two nomadicity cases to their own

Ok.

> ==> "doesn't represent any innovation" -- I don't understand, remove ?

Possibly "The auto-transition approach doesn't represent any advantage in this case".

>           auto-transition algorithm has to options:

Ok.

**********************************
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: Pekka Savola <[email-masked]>
Date: Mon, 2 Aug 2004 16:16:54 +0300 (EEST)

Inline.. (I snipped some more trivial issues)

On Sun, 1 Aug 2004, JORDI PALET MARTINEZ wrote:
> I partially don't agree. I agree that some times the "network
> administrator" (i.e., enterprise), don't want to the user to punch
> the NAT/firewall, but in some circumstances, the issue is more a
> non-technical knowledge of the user to do that, so we need to
> describe a solution (which can be or not provided in the specific
> implementation).

I'm not sure which scenario you're targeting and who you refer to with
"user".  Unmanaged networks?  All of those NAT boxes etc. practically
allow you initiate new outgoing UDP "sessions", right?  Enterprise
networks?  Many allow outgoing UDP sessios as well, and those which
don't disallow it for security etc. reasons and we don't want to
cirucmvent that (and such organizations very likely block other kinds
of packets as well, such as TCP so it wouldn't work in any case).

Therefore I think having this consideration in the draft is 
counter-productive, at least without strong warnings and disclaimers.

> Yes, once we detect the scenario, and what mechanisms are possible,
> one is "best", then we actually enable it.

OK; (I misunderstood the algorithm at first -- the loop doesn't 
iterate over the mechanisms, but over time, to detect if the scenario 
the user is in might have changed.)

> Yes and not ... we are considering to extend this document to cover
> both sides of the history ... then DSTM could play an important
> paper there.

I'd keep that out for now, or just cover it in an appendix (or the
like)... because the auto-discovery on v6-only networks vs v4-only
networks has really different assumptions..
 
> You mean activate multiple transition mechanism and actually make
> use of both ? Not really sure if we want to put the host in a
> multi-homing situation. Is this good ?. Or I'm not figuring out what
> you are trying to say ?

Isn't this what e.g., Windows hosts are doing today?

That is, you can use 6to4 or Teredo (for example) as optimization
methods when talking to 6to4 or Teredo nodes, even if you have native
IPv6 connectivity.  The case is the strongest with 6to4.  This
obviates the need to use a relay in the network, and optimizes the
connectivity (if you assume that direct v4 connectivity would be
optimal).

The use of such a mechanism could be either outbound only (e.g., 
practically a host- or site-specific outgoing 6to4 relay), or 
inbound/outbound (e.g., would generate 6to4 addresses as well and 
publish them, so that 6to4 nodes would have better connectivity when 
they initiate connections to your DNS names).

> Yes, we mean that if MIPv6 is choosen as an option (either
> automatically or by the user by means of a wizard), then ... The
> problem here is if the user has access to a HA or not.

You mean that the situation is greatly simplified if the user can use 
a Home Agent, but you'd want to also address the scenario where the 
user does not have a Home Agent?

That's OK if you make it clearer, but I'd like to reconsider whether 
trying to reinvent (parts of) Mobile IP makes sense.. (it would better 
for the user to just use Mobile IP!)  -- at least you shouldn't aim to 
achieve the same (but only a subset of scenarios) as Mobile IP..
 
> Our point here is precisely that the provision of PBN could motivate
> the ISPs to start the transition, because they can take the
> opportunity to do other "policy" based services at the same time. Is
> not only a DNS record, but a managed transition that also provides
> the ISP the way to control the process and provide higher quality of
> the transition service.

I mean, do you suggest that the ISP would deploy PBN just (initially) 
for v6 transition?  This doesn't seem practical to me.. and I doubt 
that it would happen -- hence I would like to reduce the emphasis of 
PBNs here.  It's really something that should be described in a 
totally separate I-D (or appendix, or whatever).

> I don't understand why you say that auto-trans can't do that ? Or
> you mean that is not useful because is done already by the mechanism
> itself ? But if so, that only happens once the mechanism is
> launched, and auto-trans goal is to select the right mechanism
> before its started.

Yes, I meant that it probably isn't feasible to do that by auto-trans 
because it's done by the mechanisms.  If you do that prior to 
launching the mechanism, you do a lot of duplicate work.  If you do it 
after launching a mechanism, you aren't really "detecting" anything in 
auto-trans, just using the knowledge which the mechanism learned about 
the environment.

How I see this is that auto-trans, in its most basic form, should
first try to cut down the number of mechanisms to evaluate based on
"passive analysis" (e.g., checking whether IP address is private or
not).  

After that, it needs to test the mechanisms in some order: that could
be done either by launching the mechanism and seeing if it succeeds or
not (and if not, try to figure out how it failed, and try the next
one), or by reproducing some code from the mechanisms and try to do
some "active investigation" in the network itself (e.g., send a
specific kind of test packet outside (where?) and see if you get it
back).  The former approach would possibly be preferable.

> In the case that you are already connected, for example, to a TB and
> you're moving to a network that offers a better TB option (nearer
> one).

how about "the one being already used"

> Possibly "The auto-transition approach doesn't represent any

OK :)

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Tue, 3 Aug 2004 17:58:43 +0200

Hi Pekka, all,

my reply bellow, in line.

> counter-productive, at least without strong warnings and disclaimers.

The objective of  section 3.3 isn't to overcome the filters that network administrators setup for security reasons but avoiding that non-technical users (everybody in general) can't enjoy v6 everywhere.

A lot of home-automation devices will come with IPv6 support. Such devices only will be used by the users if they have plug-and-play features. Of course with native IPv6 networks this support is guarantied, but what about IPv4 only domestic networks. Most of the time, users don't know anything about the configuration of their own network, so the auto-transition mechanism has to do the work instead the user.

The auto-transition mechanism (which can be implemented into the home-automation devices) will search the best way to get IPv6 connectivity if the NAT/Firewall box at the user's home is not configured to forward UPD/proto-41 packets.

Maybe the I-D should explain strongly this focus with warnings and disclaimers to avoid it become counter-productive.

> networks has really different assumptions..

yes, maybe you are right and including v6-only network items in this I-D is too ambitious. Maybe it is better to move DTSM to other further complementary I-D that addresses auto-transition in v6-only networks.

> achieve the same (but only a subset of scenarios) as Mobile IP..

If user can't reach a HA, it means that MIPv6 capability can't be used. We don't like to solve the point that using MIPv6 when no HA is available. We have enough stuff in this I-D ;-)

In general, the inclusion of MIPv6 concepts in the I-D is to address devices that need to be tracked  (cars, suitcases, etc.). If MIPv6 has to be used, it will influence on the selection of the transition mechanism because it can't have the IPv4 address embedded into the IPv6 one, that is, the IPv6 address can't depend on the IPv4 network where the device is attached to. Section 4 tries to explain this.

> totally separate I-D (or appendix, or whatever).

No, we don't mean that ISPs would deploy PBN just for v6 transition. Transition policies would be only one more service that ISPs might offer, just in case they have already deployed PBN for other services like security, routing, QoS and so on. If so, the auto-transition will take advantage of it to easily manage the v6 connectivity. If don't so, the auto-transition mechanism has to work also, likely less easily. 

Our main focus is on the user side, so the auto-transition behavior is defined according to that approach. However, the v6 connectivity process can be improved if the network provides some useful information to the auto-transition mechanism. For this reason we describe what we call Network Managed Transition. 

From the network approach, PBN seems to be a good alternative to help ISP to provide different types of access to users according to their category, that is, a golden user would have better QoS, so ISP could offer a different transition mechanism than a bronze user with poorer QoS. Interactions among different policies like type of user (AAA), QoS and transition mechanism to be used can be supported on this framework. Given the fact that this new approach open new powerful possibilities, it is worth to address it as much as possible.

> back).  The former approach would possibly be preferable.

why  can't the auto-transition mechanism check the NAT type? The result of such a test will strongly influence on the type of transition mechanism to be choosen /checked (6in4, Teredo, etc). For exameple: if the NAT box doesn't forward proto-41, why to check 6in4 tunnels? So the auto-trans should do it. Then a reduced list of mechanisms fitting with the NAT check result will be choosen from the general candidate list in order to check it some of them can be choosen.

I agree this behaviour can duplicate the work if the final mechanism also check the type of NAT (Teredo), but not all of them do it, so it is necessary, even although some times it means duplicate work

Best Regards
Miguel

---

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Aug 2004 19:21:27 +0300 (EEST)

On Tue, 3 Aug 2004, Miguel Angel Diaz wrote:
> The objective of section 3.3 isn't to overcome the filters that
> network administrators setup for security reasons but avoiding that
> non-technical users (everybody in general) can't enjoy v6
> everywhere.
[...]
> 
> The auto-transition mechanism (which can be implemented into the
> home-automation devices) will search the best way to get IPv6
> connectivity if the NAT/Firewall box at the user's home is not
> configured to forward UPD/proto-41 packets.

The point I'm making is that NAT/firewall boxes *do* forward UDP 
packets, or else a *LOT* of different things break -- like DNS, IKE 
negotiation for IPsec, a dozen of other protocols.

I've never seen a NAT/firewall which wouldn't support UDP "sessions", 
and I don't recall any case (e.g., in homes) where outgoing UDP 
packets would not be allowed through.

Therefore I'm strongly objecting to this approach.  It seems to add a 
hack for a non-problem (for 99.99% of users), in a manner that creates 
problems for everyone when there is no IPv6 tunnel endpoint (e.g., if 
there just isn't any IPv6 connectivity available, this forces all the 
users to try all the mechanisms).

Further, this adds confusion to the mechanisms "market" by making it 
look like there's actual, real need for these other TCP etc. tunneling 
methods.  I don't think there is, and I think doing so would be 
counter-productive.

A good auto-transition algorithm would be one that has a minimum 
number of steps, not the maximum number of steps.  There's no way we 
can guarantee with 100% certainty that the users are always able to 
get v6 connectivity (if there's just no provider providing one).  
Trying to address 95, 99, or 99.9% case should be sufficient (and much 
simpler).

> If user can't reach a HA, it means that MIPv6 capability can't be
> used. We don't like to solve the point that using MIPv6 when no HA
> is available. We have enough stuff in this I-D ;-)

So, you're concerned about the case that the user does have a HA, but 
there may be some problem with connectivity to the HA? (compared to 
the user having no HA at all)

That's something that needs to be made clearer -- but actually I don't 
think this would be a realistic scenario.  If the user has service 
from the HA, it would seem reasonable to expect that the user is able 
to get that service.

> In general, the inclusion of MIPv6 concepts in the I-D is to address
> devices that need to be tracked (cars, suitcases, etc.). If MIPv6
> has to be used, it will influence on the selection of the transition
> mechanism because it can't have the IPv4 address embedded into the
> IPv6 one, that is, the IPv6 address can't depend on the IPv4 network
> where the device is attached to. Section 4 tries to explain this.

I don't understand your point.  Even if you use MIPv6, CoA can of 
course be whatever (include v4 address or whatever).

I don't understand at all why you'd want to track e.g. suitcases using 
MIPv6 or IP address, but that's out of scope from here.. 

> No, we don't mean that ISPs would deploy PBN just for v6 transition.
> Transition policies would be only one more service that ISPs might
> offer, just in case they have already deployed PBN for other
> services like security, routing, QoS and so on. If so, the
> auto-transition will take advantage of it to easily manage the v6
> connectivity. If don't so, the auto-transition mechanism has to work
> also, likely less easily.

Can you list a few ISPs which have deployed PBNs?  If such ISPs are 
not commonplace (I haven't heard of any), this isn't really relevant.

Remember, the IETF has discontinued PBN development a couple of years 
ago AFAIR.
 
> why can't the auto-transition mechanism check the NAT type? The
> result of such a test will strongly influence on the type of
> transition mechanism to be choosen /checked (6in4, Teredo, etc). For
> exameple: if the NAT box doesn't forward proto-41, why to check 6in4
> tunnels? So the auto-trans should do it. Then a reduced list of
> mechanisms fitting with the NAT check result will be choosen from
> the general candidate list in order to check it some of them can be
> choosen.

Checking for forwarding proto-41 is one thing, checking for the 
more detailed properties of NAT (e..g, as Teredo does) is probably not 
worth the effort as it just creates duplicated work, additional 
packets, delays in setting up connectivity, etc.

Still, checking proto-41 forwarding support is far from trivial.  
Which IP address do you send such a probe to?  You don't have the IP
address of the potential tunnel server available yet...