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

[Pekka Savola <pekkas@netcore.fi>]

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).

> > 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..
> 
> 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.. 

> > 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).
> 
> 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...

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